Side link feedback channel

文档序号：144789 发布日期：2021-10-22 浏览：25次中文

阅读说明：本技术 侧链路反馈信道 (Side link feedback channel ) 是由叶春宣郗风君凯尔·正林·潘于 2020-01-09 设计创作，主要内容包括：WTRU可以选择侧链路单播或组播来传送数据。如果WTRU选择侧链路单播,则WTRU可以选择使用HARQ ACK/NACK反馈用于所述传输。如果WTRU选择了侧链路组播,则可以根据一个或多个因素来选择HARQNACK或HARQ ACK/NACK。所述WTRU可以根据以下中的一者或多者来选择HARQ NACK或HARQ ACK/NACK：接收所述数据的WTRU的数量；与传输相关联的信道的状况；或者与传输相关联的服务质量。所述WTRU可以基于一个或多个因素选择第一或第二PSFCH格式用于反馈。所述WTRU可以基于以下中的一者或多者来选择第一PSFCH格式或第二PSFCH格式：所选择的侧链路单播或组播；所选择的HARQ NACK或HARQ ACK/NACK反馈；或者与所述传输相关联的服务质量。(The WTRU may select either side link unicast or multicast to transmit data. The WTRU may choose to use HARQ ACK/NACK feedback for the transmission if the WTRU chooses side link unicast. The HARQ NACK or HARQ ACK/NACK may be selected based on one or more factors if the WTRU selects sidelink multicast. The WTRU may select a HARQ NACK or a HARQ ACK/NACK according to one or more of: a number of WTRUs receiving the data; a condition of a channel associated with the transmission; or a quality of service associated with the transmission. The WTRU may select the first or second PSFCH format for feedback based on one or more factors. The WTRU may select the first or second PSFCH format based on one or more of: unicasting or multicasting the selected side link; selected HARQ NACK or HARQ ACK/NACK feedback; or a quality of service associated with the transmission.)

1. A method for sidelink communications, comprising:

a Wireless Transmit and Receive Unit (WTRU) determining that data is to be transmitted via a sidelink transmission;

the WTRU selecting either sidelink unicast or sidelink multicast to transmit the data;

the WTRU selecting HARQ ACK/NACK feedback for use as feedback associated with transmission of the data, conditioned on: a side link unicast is selected for transmitting the data;

the WTRU selects HARQ NACK feedback or HARQ ACK/NACK feedback, conditioned on: side link multicast is selected for transmitting the data, and one or more of: a number of WTRUs receiving the data, a condition of a channel associated with transmitting the data, or a quality of service associated with transmitting the data;

the WTRU selects either a first PSFCH format or a second PSFCH format, conditioned on one or more of: selected side link unicast or side link multicast, selected HARQ NACK feedback or HARQ ACK/NACK feedback, or a quality of service associated with transmitting the data; and

the WTRU transmitting the data using the selected sidelink unicast or sidelink multicast and information indicating the selected first or second PSFCH format and the selected HARQ NACK or HARQ ACK/NACK feedback.

2. The method of claim 1, wherein,

wherein, HARQ NACK feedback or HARQ ACK/NACK feedback is selected, which is conditioned on: side link multicast is selected for transmitting the data, and one or more of: the number of WTRUs receiving the data, the condition of a channel associated with transmitting the data, or the quality of service associated with transmitting the data, including:

selecting HARQ NACK feedback, conditioned on one or more of: the number of WTRUs to receive the data is greater than a threshold, the channel associated with transmitting the data has a high load, or the quality of service associated with transmitting the data is not highly reliable or delay critical.

3. The method of claim 1, wherein,

selecting HARQ ACK/NACK feedback, conditioned on one or more of: the number of WTRUs to receive the data is less than a threshold, the channel associated with transmitting the data has a low load, or the quality of service associated with transmitting the data is highly reliable or delay critical.

4. The method of claim 1, wherein,

wherein the first or second PSFCH format is selected, subject to one or more of: selected side link unicast or side link multicast, selected HARQ NACK feedback or HARQ ACK/NACK feedback, or a quality of service associated with transmitting the data, comprising:

selecting the first PSFCH format, subject to the following conditions: side-link unicast is selected, HARQ ACK/NACK feedback is selected, and the quality of service associated with transmitting the data is not highly reliable.

5. The method of claim 1, wherein,

selecting the second PSFCH format, subject to the following conditions: side-link unicast is selected, HARQ ACK/NACK feedback is selected, and the quality of service associated with transmitting the data is high reliability.

6. The method of claim 1, wherein,

selecting the first PSFCH format, subject to the following conditions: side-link multicast is selected and HARQ NACK feedback is selected.

7. The method of claim 1, wherein,

selecting the first PSFCH format, subject to the following conditions: side link multicast is selected, HARQ ACK/NACK feedback is selected, and the quality of service associated with transmitting the data is not highly reliable.

8. The method of claim 1, wherein,

9. The method of claim 1, wherein,

selecting the second PSFCH format, subject to the following conditions: side-link multicast is selected, HARQ ACK/NACK feedback is selected, and the quality of service associated with transmitting the data is high reliability.

10. The method of claim 1, wherein,

selecting the second PSFCH format, subject to the following conditions: side link multicast is selected, HARQ ACK/NACK feedback is selected, and the quality of service associated with transmitting the data is highly reliable and has a large minimum communication range.

11. The method of claim 1, further comprising the WTRU receiving feedback using the selected HARQ NACK or HARQ ACK/NACK and the selected first or second PSFCH format.

12. A wireless transmit and receive unit (WRTU), comprising:

a processor; and

a computing memory communicatively coupled with the processor, the computing memory having executable instructions stored thereon that cause the WTRU to perform operations comprising:

determining that data is to be transmitted via sidelink transmission;

selecting either side link unicast or side link multicast to transmit the data;

selecting HARQ ACK/NACK feedback for use as feedback associated with transmission of the data, conditioned on: a side link unicast is selected for transmitting the data;

selecting HARQ NACK feedback or HARQ ACK/NACK feedback, conditioned on: side link multicast is selected for transmitting the data, and one or more of: a number of WTRUs receiving the data, a condition of a channel associated with transmitting the data, or a quality of service associated with transmitting the data;

selecting either the first PSFCH format or the second PSFCH format, subject to one or more of: selected side link unicast or side link multicast, selected HARQ NACK feedback or HARQ ACK/NACK feedback, or a quality of service associated with transmitting the data; and

transmitting the data and information indicating the selected first or second PSFCH format and the selected HARQ NACK or HARQ ACK/NACK feedback using the selected sidelink unicast or sidelink multicast.

13. The WTRU of claim 12, wherein,

14. The WTRU of claim 12, wherein,

15. The WTRU of claim 12, wherein,

Background

A wireless communication device may establish communication with other devices and data networks via various access networks. For example, the wireless communication device may establish communication via a 3GPP Radio Access Network (RAN) and/or a 5G (e.g., New Radio (NR)) RAN. The wireless communication device may access the RAN to communicate with other wireless devices and to access a data network communicatively coupled with the RAN.

A wireless communication device may establish direct communication with other wireless communication devices. For example, a wireless communication device may communicate with another wireless communication device without the need for communication through the RAN. Such direct device-to-device communication may be referred to as sidelink communication.

Disclosure of Invention

Systems and implementations for providing feedback for sidelink communications are disclosed herein. A computing system, which may be, for example, a Wireless Transmit and Receive Unit (WTRU), may be programmed to determine that data is to be transmitted via a sidelink transmission, and may determine a type of feedback that may be used in connection with the sidelink transmission.

The WTRU may select a sidelink unicast transmission or a sidelink multicast transmission to transmit the data. The WTRU may select HARQ ACK/NACK feedback for feedback associated with the data transmission if the WTRU selects side link unicast to transmit the data.

The HARQ NACK feedback or HARQ ACK/NACK feedback may be selected for feedback based on one or more factors or conditions if the WTRU selects a sidelink multicast transmission to transmit the data. The WTRU may select HARQ NACK feedback or HARQ ACK/NACK feedback for transmission of the data based on or conditional on: side link multicast is selected to transmit the data, and one or more of: a number of WTRUs used to receive the data, a condition of a channel associated with transmitting the data, or a quality of service associated with transmitting the data. The WTRU may select HARQ NACK feedback based on or conditional on: the number of WTRUs receiving the data is greater than a threshold, the channel associated with transmitting the data has a high load, or the quality of service associated with transmitting the data is not highly reliable or non-delay critical. The WTRU may select HARQ ACK/NACK feedback based on or conditional on: the number of WTRUs receiving the data is less than a threshold, the channel associated with transmitting the data has a low load, or the quality of service associated with transmitting the data is highly reliable or delay critical.

The WTRU may select the first or second PSFCH format to provide feedback based on one or more factors or conditions. The first PSFCH format may be, for example, PSFCH format 0, and the second PSFCH format may be, for example, PSFCH format 1. The WTRU may select the first or second PSFCH format based on or conditional on one or more of: selected side link unicast or side link multicast, selected HARQ NACK feedback or HARQ ACK/NACK feedback, or a quality of service associated with transmitting the data. The WTRU may select the first PSFCH format based on or conditional on: the side-link unicast is selected, the HARQ ACK/NACK feedback is selected, and the quality of service associated with transmitting data is not high reliability. The WTRU may select the second PSFCH format based on or conditional on: side-link unicast is selected, HARQ ACK/NACK feedback is selected, and the quality of service associated with transmitting the data is high reliability. The WTRU may select the first PSFCH format based on or conditional on: side-link multicast is selected and HARQ NACK is selected. The WTRU may select the first PSFCH format based on or conditional on: side link multicast is selected, HARQ ACK/NACK feedback is selected, and the quality of service associated with transmitting the data is not highly reliable. The WTRU may select the first PSFCH format based on or conditional on: side link multicast is selected, HARQ ACK/NACK feedback is selected, and the quality of service associated with transmitting the data is not high reliability and does not have a large minimum communication range. The WTRU may select the second PSFCH format based on or conditional on: side link multicast is selected, HARQ ACK/NACK feedback is selected, and the quality of service associated with transmitting the data is high reliability. The WTRU may select the second PSFCH format based on or conditional on: side link multicast is selected, HARQ ACK/NACK feedback is selected, and the quality of service associated with transmitting the data is highly reliable and has a large minimum communication range.

The WTRU may transmit the data using the selected sidelink unicast or sidelink multicast. The WTRU may also transmit information indicating the selected first or second PSFCH format and information indicating the selected HARQ NACK or HARQ ACK/NACK feedback. The WTRU may then receive feedback regarding the sidelink communication using the selected HARQ NACK or HARQ ACK/NACK and the selected first or second PSFCH format.

This summary is provided to introduce a selection of concepts in a simplified form. These concepts are further described in the detailed description. This summary is not intended to limit the scope of the claimed subject matter. Other features are described herein.

Drawings

A more detailed understanding can be obtained from the following description, given by way of example, in conjunction with the accompanying drawings, in which:

FIG. 1A is a system diagram illustrating an exemplary communication system in which one or more disclosed embodiments may be implemented;

figure 1B is a system diagram illustrating an exemplary wireless transmit/receive unit (WTRU) that may be used within the communication system shown in figure 1A, according to an embodiment;

fig. 1C is a system diagram illustrating an exemplary Radio Access Network (RAN) and an exemplary Core Network (CN) that may be used within the communication system shown in fig. 1A, according to an embodiment;

figure 1D is a system diagram illustrating another exemplary RAN and another exemplary CN that may be used within the communication system shown in figure 1A, according to an embodiment;

fig. 2 illustrates an example sharing of PSFCH resources for sidelink communications.

Fig. 3 shows an example selection of HARQ feedback scheme and PSFCH format.

FIG. 4 illustrates example resource sensing.

Fig. 5 shows an example PSCCH and PSCCH decoding.

Fig. 6 illustrates an example reporting schedule.

Fig. 7 illustrates an example reporting schedule.

Fig. 8 shows an example activation of SFCI piggyback on PSSCH.

Fig. 9 shows an example activation of SFCI piggybacking on a psch.

Fig. 10 shows an example activation of SFCI piggybacking on a psch.

Fig. 11 illustrates exemplary sideline communications.

Fig. 12 illustrates exemplary sideline communications.

Detailed Description

Techniques for selecting a feedback format to be used with sidelink communications are described. The WTRU may choose to transmit data using either sidelink unicast transmission or sidelink multicast transmission. Depending on the selected transmission type and one or more additional factors, the WTRU may choose to use HARQ ACK/NACK or HARQ NACK feedback related to transmitting the data. The WTRU may also choose to use either PSFCH format 0 or PSFCH format 1 for feedback depending on whether unicast or multicast communication is used and one or more additional factors.

Fig. 1A is a diagram illustrating an exemplary communication system 100 in which one or more disclosed embodiments may be implemented. The communication system 100 may be a multiple-access system that provides content, such as voice, data, video, messaging, broadcast, etc., to a plurality of wireless users. The communication system 100 may enable multiple wireless users to access such content by sharing system resources, including wireless bandwidth. For example, communication system 100 may use 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-tailed unique word DFT-spread OFDM (ZT UW DTS-s OFDM), unique word OFDM (UW-OFDM), resource block filtered OFDM, and filter bank multi-carrier (FBMC), among others.

As shown in fig. 1A, the communication system 100 may include wireless transmit/receive units (WTRUs) 102a, 102b, 102c, 102d, RANs 104/113, CNs 106/115, Public Switched Telephone Networks (PSTNs) 108, the internet 110, and other networks 112, although it should be appreciated that any number of WTRUs, base stations, networks, and/or network components are contemplated by the disclosed embodiments. The WTRUs 102a, 102b, 102c, 102d may each be any type of device configured to operate and/or communicate in a wireless environment. For example, any of the WTRUs 102a, 102b, 102c, 102d may be referred to as a "station" and/or a "STA," which 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 (IoT) device, a watch or other wearable device, a head-mounted display (HMD), a vehicle, a drone, a medical device and application (e.g., tele-surgery), an industrial device and application (e.g., a robot and/or other wireless device operating in an industrial and/or automated processing chain environment), a consumer electronics device, a wireless transceiver, or a wireless device, or a wireless device, a wireless transceiver, a wireless device, or a wireless device, a wireless device, And devices operating on commercial and/or industrial wireless networks, and the like. Any of the WTRUs 102a, 102b, 102c, 102d may be referred to interchangeably as a UE.

The communication system 100 may also include a base station 114a and/or a base station 114 b. Each of the base stations 114a, 114b may be any type of device configured to facilitate access to one or more communication networks (e.g., CN 106/115, the internet 110, and/or other networks 112) by wirelessly interfacing with at least one of the WTRUs 102a, 102b, 102c, 102 d. For example, the base stations 114a, 114B may be Base Transceiver Stations (BTSs), node B, e node bs, home enodebs, gnbs, NR node bs, site controllers, Access Points (APs), and wireless routers, among others. Although each of the base stations 114a, 114b is depicted as a single component, it should be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and/or network components.

The base station 114a may be part of the RAN 104/113, and the RAN may also include other base stations and/or network components (not shown), such as Base Station Controllers (BSCs), Radio Network Controllers (RNCs), relay nodes, and so forth. Base station 114a and/or base station 114b may be configured to transmit and/or receive wireless signals on one or more carrier frequencies, known as cells (not shown). These frequencies may be in the licensed spectrum, the unlicensed spectrum, or a combination of the licensed and unlicensed spectrum. A cell may provide wireless service coverage for a particular geographic area that is relatively fixed or may vary over time. The cell may be further divided into cell sectors. For example, the cell associated with base station 114a may be divided into three sectors. Thus, in one embodiment, the base station 114a may include three transceivers, that is, each transceiver corresponds to a sector of a cell. In an embodiment, base station 114a may use multiple-input multiple-output (MIMO) technology and may use multiple transceivers for each sector of a cell. For example, using beamforming, signals may be transmitted and/or received in desired spatial directions.

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, millimeter-wave, Infrared (IR), Ultraviolet (UV), visible, etc.). Air interface 116 may be established using any suitable Radio Access Technology (RAT).

More specifically, as described above, communication system 100 may be a multiple-access system and may use one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, and SC-FDMA, among others. For example, the base station 114a and the WTRUs 102a, 102b, 102c in the RAN 104/113 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).

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-Pro (LTE-a Pro).

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

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 collectively implement LTE radio access and NR radio access (e.g., using Dual Connectivity (DC) principles). As such, the air interface used by the WTRUs 102a, 102b, 102c may be characterized by multiple types of radio access technologies and/or transmissions sent to/from multiple types of base stations (e.g., eNB and gNB).

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 high fidelity (WiFi)), IEEE 802.16 (worldwide interoperability for microwave Access (WiMAX)), CDMA2000, CDMA 20001X, CDMA2000EV-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), and GSM EDGE (GERAN), among others.

The base station 114B in fig. 1A may be, for example, a wireless router, a home nodeb, a home enodeb, or an access point, and may facilitate wireless connectivity in a local area using any suitable RAT, such as a business, a residence, a vehicle, a campus, an industrial facility, an air corridor (e.g., for use by a drone), and a road, among others. In one embodiment, the base station 114b and the WTRUs 102c, 102d may establish a Wireless Local Area Network (WLAN) by implementing a radio technology such as IEEE 802.11. In an embodiment, the base station 114b and the WTRUs 102c, 102d may establish a Wireless Personal Area Network (WPAN) by implementing a radio technology such as IEEE 802.15. In yet another embodiment, the base station 114b and the WTRUs 102c, 102d may establish the pico cell or the femto cell by using a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE-A, LTE-a Pro, NR, etc.). As shown in fig. 1A, the base station 114b may be directly connected to the internet 110. Thus, base station 114b need not access the internet 110 via CN 106/115.

The RAN 104/113 may communicate with a 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, 102 d. The data may have different quality of service (QoS) requirements, such as different throughput requirements, latency requirements, fault tolerance requirements, reliability requirements, data throughput requirements, and mobility requirements, among others. CN 106/115 may provide call control, billing services, mobile location-based services, pre-paid calling, internet connectivity, video distribution, etc., and/or may perform advanced security functions such as user authentication. Although not shown in fig. 1A, it should be appreciated that the RAN 104/113 and/or CN 106/115 may communicate directly or indirectly 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 using NR radio technology, the CN 106/115 may communicate with another RAN (not shown) using GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi radio technologies.

The CN 106/115 may also act as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the internet 110, and/or other networks 112. The PSTN 108 may include a circuit-switched telephone network that provides Plain Old Telephone Service (POTS). The internet 110 may include a system of globally interconnected computer network devices that utilize common communication protocols, such as transmission control protocol/internet protocol (TCP), User Datagram Protocol (UDP), and/or IP in the TCP/IP internet protocol suite. The network 112 may include wired or wireless communication networks owned and/or operated by other service providers. For example, the network 112 may include another CN connected to one or more RANs, which may use the same RAT as the RAN 104/113 or a different RAT.

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

Figure 1B is a system diagram illustrating an exemplary WTRU 102. As shown in fig. 1B, the WTRU 102 may include a processor 118, a transceiver 120, a transmit/receive component 122, a speaker/microphone 124, a keypad 126, a display/touch pad 128, non-removable memory 130, removable memory 132, a power source 134, a Global Positioning System (GPS) chipset 136, and/or other peripherals 138. It should be appreciated that the WTRU 102 may include any subcombination of the foregoing components while maintaining consistent embodiments.

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, or 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 a transceiver 120 and the transceiver 120 may be coupled to a transmit/receive component 122. Although fig. 1B depicts processor 118 and transceiver 120 as separate components, it should be understood that processor 118 and transceiver 120 may be integrated together in an electronic component or chip.

The transmit/receive component 122 may be configured to transmit or receive signals to or from a base station (e.g., base station 114a) via the air interface 116. For example, in one embodiment, the transmit/receive component 122 may be an antenna configured to transmit and/or receive RF signals. As an example, in another embodiment, the transmit/receive component 122 may be an emitter/detector configured to emit and/or receive IR, UV or visible light signals. In yet another embodiment, the transmit/receive component 122 may be configured to transmit and/or receive RF and optical signals. It should be appreciated that the transmit/receive component 122 may be configured to transmit and/or receive any combination of wireless signals.

Although transmit/receive component 122 is depicted in fig. 1B as a single component, WTRU 102 may include any number of transmit/receive components 122. More specifically, the WTRU 102 may use MIMO technology. Thus, in one embodiment, the WTRU 102 may include two or more transmit/receive components 122 (e.g., multiple antennas) that transmit and receive wireless signals over the air interface 116.

Transceiver 120 may be configured to modulate signals to be transmitted by transmit/receive element 122 and to demodulate signals received by transmit/receive element 122. As described above, the WTRU 102 may have multi-mode capabilities. Thus, the transceiver 120 may include multiple transceivers that allow the WTRU 102 to communicate via multiple RATs (e.g., NR and IEEE 802.11).

The processor 118 of the WTRU 102 may be coupled to and may receive user input data from a speaker/microphone 124, a keypad 126, and/or a display/touch pad 128, such as a Liquid Crystal Display (LCD) display unit or an Organic Light Emitting Diode (OLED) display unit. The processor 118 may also output user data to the speaker/microphone 124, the keypad 126, and/or the display/touchpad 128. Further, processor 118 may access information from and store information in any suitable memory, such as non-removable memory 130 and/or removable memory 132. The non-removable memory 130 may include Random Access Memory (RAM), Read Only Memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 may include a Subscriber Identity Module (SIM) card, a memory stick, a Secure Digital (SD) memory card, and so forth. In other embodiments, the processor 118 may access information from and store data in memory that is not physically located in the WTRU 102, such memory may be located, for example, in a server or a home computer (not shown).

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

The processor 118 may also be coupled to a GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) related to the current location of the WTRU 102. In addition to or in lieu of information from the GPS chipset 136, the WTRU 102 may receive location information from base stations (e.g., base stations 114a, 114b) via the air interface 116 and/or determine its location based on the timing of signals received from two or more nearby base stations. It should be appreciated that the WTRU 102 may acquire location information via any suitable positioning method while maintaining consistent embodiments.

The processor 118 may also be coupled to other peripheral devices 138, which may include one or more software and/or hardware modules that provide additional features, functionality, and/or wired or wireless connections. For exampleThe peripheral devices 138 may include accelerometers, electronic compasses, satellite transceivers, digital cameras (for photos and/or video), Universal Serial Bus (USB) ports, vibration devices, television transceivers, hands-free headsets, video cameras, audio cameras, and/or video cameras,Modules, Frequency Modulation (FM) radio units, digital music players, media players, video game modules, internet browsers, virtual reality and/or augmented reality (VR/AR) devices, and activity trackers, among others. The peripheral device 138 may include one or more sensors, which may be one or more of the following: a gyroscope, an accelerometer, a hall effect sensor, a magnetometer, an orientation sensor, a proximity sensor, a temperature sensor, a time sensor, a geographic position sensor, an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, and/or a humidity sensor, among others.

The WTRU 102 may include a full duplex radio for which reception or transmission of some or all signals (e.g., associated with particular subframes for 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 that reduces and/or substantially eliminates self-interference via signal processing by hardware (e.g., a choke coil) or by a processor (e.g., a separate processor (not shown) or by the processor 118). In an embodiment, the WTRU 102 may include a half-duplex radio that transmits and receives some or all signals (e.g., associated with a particular subframe for UL (e.g., for transmission) or downlink (e.g., for reception)).

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

RAN 104 may include enodebs 160a, 160B, 160c, however, it should be appreciated that RAN 104 may include any number of enodebs while maintaining consistent embodiments. The enodebs 160a, 160B, 160c may each include one or more transceivers that communicate with the WTRUs 102a, 102B, 102c over the air interface 116. In one embodiment, the enodebs 160a, 160B, 160c may implement MIMO technology. Thus, for example, the enodeb 160a may use multiple antennas to transmit wireless signals to the WTRU 102a and/or to receive wireless signals from the WTRU 102 a.

The enodebs 160a, 160B, 160c may each 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 so forth. As shown in FIG. 1C, eNode Bs 160a, 160B, 160C may communicate with each other over an X2 interface.

The CN 106 shown in fig. 1C 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 components are described as being part of the CN 106, it should be appreciated that any of these components may be owned and/or operated by an entity other than the CN operator.

The MME 162 may be connected to each of the enodebs 160a, 160B, 160c in the RAN 104 via an S1 interface and may act as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, performing bearer activation/deactivation processes, and selecting a particular serving gateway during initial attach of the WTRUs 102a, 102b, 102c, among other things. MME 162 may provide a control plane function for switching between RAN 104 and other RANs (not shown) that use other radio technologies (e.g., GSM and/or WCDMA).

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

The SGW 164 may be connected to a PGW 146, which may provide packet-switched network (e.g., internet 110) access for the WTRUs 102a, 102b, 102c to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.

The CN 106 may facilitate communications with other networks. For example, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to a circuit-switched network (e.g., the PSTN 108) to facilitate communications between the WTRUs 102a, 102b, 102c and conventional landline communication devices. For example, the CN 106 may include or communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server), and the IP gateway may serve as an interface between the CN 106 and the PSTN 108. In addition, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to the other networks 112, which may include other wired and/or wireless networks owned and/or operated by other service providers.

Although the WTRU is depicted in fig. 1A-1D as a wireless terminal, it is contemplated that in some exemplary embodiments, such a terminal may use a (e.g., temporary or permanent) wired communication interface with a communication network.

In an exemplary embodiment, the other network 112 may be a WLAN.

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 access another type of wired/wireless network that is either interfaced to a Distribution System (DS) or that carries traffic into and/or out of the BSS. Traffic originating outside the BSS and destined for the STAs may arrive through the AP and be delivered to the STAs. Traffic originating from the STAs and destined for destinations outside the BSS may be sent to the AP for delivery to the respective destinations. Traffic between STAs that are inside the BSS may be transmitted through the AP, for example, in the case where the source STA may transmit traffic to the AP and the AP may deliver the traffic to the destination STA. Traffic between STAs within the BSS may be considered and/or referred to as point-to-point traffic. The point-to-point traffic may be transmitted between (e.g., directly between) the source and destination STAs using Direct Link Setup (DLS). In some exemplary embodiments, DLS may use 802.11e DLS or 802.11z channelized DLS (tdls)). For example, a WLAN using an Independent Bss (IBSS) mode has no AP, and STAs (e.g., all STAs) within or using the IBSS may communicate directly with each other. The IBSS communication mode may sometimes be referred to herein as an "Ad-hoc" communication mode.

When using the 802.11ac infrastructure mode of operation or similar mode of operation, the AP may transmit a beacon on a fixed channel (e.g., a primary channel). The primary channel may have a fixed width (e.g., 20MHz bandwidth) or a width that is dynamically set via signaling. The primary channel may be the operating channel of the BSS and may be used by the STA to establish a connection with the AP. In some exemplary embodiments, implemented may be carrier sense multiple access with collision avoidance (CSMA/CA) (e.g., in 802.11 systems). For CSMA/CA, STAs (e.g., each STA) including the AP may sense the primary channel. A particular STA may back off if it senses/detects and/or determines that the primary channel is busy. In a given BSS, there is one STA (e.g., only one station) transmitting at any given time.

High Throughput (HT) STAs may communicate using 40MHz wide channels (e.g., 40MHz wide channels formed by combining a20 MHz wide primary channel with 20MHz wide adjacent or non-adjacent channels).

Very High Throughput (VHT) STAs may support channels that are 20MHz, 40MHz, 80MHz, and/or 160MHz wide. 40MHz and/or 80MHz channels may be formed by combining consecutive 20MHz channels. The 160MHz channel may be formed by combining 8 consecutive 20MHz channels or by combining two discontinuous 80MHz channels (this combination may be referred to as an 80+80 configuration). For the 80+80 configuration, after channel encoding, the data may be passed through a fragment parser that may divide the data into two streams. Inverse Fast Fourier Transform (IFFT) processing and time domain processing may be performed separately on each stream. The streams may be mapped on two 80MHz channels and data may be transmitted by STAs performing the transmissions. At the receiver of the STA performing the reception, the above-described operations for the 80+80 configuration may be reversed, and the combined data may be transmitted to a Medium Access Control (MAC).

802.11af and 802.11ah support operating modes below 1 GHz. The use of channel operating bandwidths and carriers in 802.11af and 802.11ah is reduced compared to 802.11n and 802.11 ac. 802.11af supports 5MHz, 10MHz, and 20MHz bandwidths in the TV white space (TVWS) spectrum, and 802.11ah supports 1MHz, 2MHz, 4MHz, 8MHz, and 16MHz bandwidths using non-TVWS spectrum. In accordance with an exemplary embodiment, the 802.11ah may support meter type control/machine type communication (e.g., MTC devices in a macro coverage area). MTC devices may have certain capabilities, such as limited capabilities including supporting (e.g., supporting only) certain and/or limited bandwidth. The MTC device may include a battery, and the battery life of the battery is above a threshold (e.g., to maintain a long battery life).

For WLAN systems (e.g., 802.11n, 802.11ac, 802.11af, and 802.11ah) that can support multiple channels and channel bandwidths, these systems contain channels that can be designated as primary channels. The bandwidth of the primary channel may be equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be set and/or limited by a STA that is sourced from all STAs operating in the BSS supporting the minimum bandwidth operating mode. In an example for 802.11ah, even though the AP and other STAs in the BSS support 2MHz, 4MHz, 8MHz, 16MHz, and/or other channel bandwidth operating modes, the width of the primary channel may be 1MHz for STAs (e.g., MTC-type devices) that support (e.g., only support) 1MHz mode. Carrier sensing and/or Network Allocation Vector (NAV) setting may depend on the state of the primary channel. If the primary channel is busy (e.g., because STAs (which support only 1MHz mode of operation) transmit to the AP), the entire available band may be considered busy even though most of the available band remains free and available for use.

In the united states, the available frequency band available for 802.11ah is 902MHz to 928 MHz. In korea, the available frequency band is 917.5MHz to 923.5 MHz. In Japan, the available frequency band is 916.5MHz to 927.5 MHz. The total bandwidth available for 802.11ah is 6MHz to 26MHz, in accordance with the country code.

Figure 1D is a system diagram illustrating RAN 113 and CN 115 according to an embodiment. As described above, the RAN 113 may communicate with the WTRUs 102a, 102b, 102c using NR radio technology over the air interface 116. RAN 113 may also communicate with CN 115.

RAN 113 may include gnbs 180a, 180b, 180c, but it should be appreciated that RAN 113 may include any number of gnbs while maintaining consistent embodiments. The gnbs 180a, 180b, 180c may each include one or more transceivers to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the gnbs 180a, 180b, 180c may implement MIMO techniques. For example, the gnbs 180a, 180b may use beamforming processing to transmit and/or receive signals to and/or from the gnbs 180a, 180b, 180 c. Thus, for example, the gNB 180a may use multiple antennas to transmit wireless signals to the WTRU 102a and to receive wireless signals from the WTRU 102 a. In an embodiment, the gnbs 180a, 180b, 180c may implement carrier aggregation techniques. 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 the unlicensed spectrum, while the remaining component carriers may be on the licensed spectrum. In an embodiment, the gnbs 180a, 180b, 180c may implement coordinated multipoint (CoMP) techniques. For example, WTRU 102a may receive a cooperative transmission from gNB 180a and gNB 180b (and/or gNB 180 c).

The WTRUs 102a, 102b, 102c may communicate with the gnbs 180a, 180b, 180c using transmissions associated with a scalable digital configuration. For example, the OFDM symbol spacing and/or OFDM subcarrier spacing may be different for different transmissions, different cells, and/or different portions of the wireless transmission spectrum. The WTRUs 102a, 102b, 102c may communicate with the gnbs 180a, 180b, 180c using subframes or Transmission Time Intervals (TTIs) having different or scalable lengths (e.g., including different numbers of OFDM symbols and/or lasting different absolute time lengths).

The gnbs 180a, 180b, 180c may be configured to communicate with WTRUs 102a, 102b, 102c in independent configurations and/or non-independent configurations. In a standalone configuration, the WTRUs 102a, 102B, 102c may communicate with the gnbs 180a, 180B, 180c without accessing other RANs (e.g., enodebs 160a, 160B, 160 c). In a standalone configuration, the WTRUs 102a, 102b, 102c may use one or more of the gnbs 180a, 180b, 180c as mobility anchors. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gnbs 180a, 180b, 180c using signals in an unlicensed frequency band. In a non-standalone configuration, the WTRUs 102a, 102B, 102c may communicate/connect with the gnbs 180a, 180B, 180c while communicating/connecting with other RANs (e.g., enodebs 160a, 160B, 160 c). For example, the WTRUs 102a, 102B, 102c may communicate with one or more gnbs 180a, 180B, 180c and one or more enodebs 160a, 160B, 160c in a substantially simultaneous manner by implementing DC principles. In a non-standalone configuration, the enode bs 160a, 160B, 160c may serve as mobility anchors for the WTRUs 102a, 102B, 102c, and the gnbs 180a, 180B, 180c may provide additional coverage and/or throughput to serve the WTRUs 102a, 102B, 102 c.

The gnbs 180a, 180b, 180c may each be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, user scheduling in UL and/or DL, support network slicing, dual connectivity, implement interworking processing between NR and E-UTRA, route user plane data to User Plane Functions (UPFs) 184a, 184b, and route control plane information to access and mobility management functions (AMFs) 182a, 182b, among other things. As shown in fig. 1D, the gnbs 180a, 180b, 180c may communicate with each other over an Xn interface.

The CN 115 shown in fig. 1D 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, 185 b. While each of the foregoing components are depicted as being part of the CN 115, it should be appreciated that any of these components may be owned and/or operated by an entity other than the CN operator.

The AMFs 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 act as control nodes. For example, the AMFs 182a, 182b may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, supporting network slicing (e.g., handling different PDU sessions with different requirements), selecting specific SMFs 183a, 183b, managing registration areas, terminating NAS signaling, and mobility management, among others. The AMFs 182a, 182b may use network slicing processing to customize the CN support provided for the WTRUs 102a, 102b, 102c based on the type of service the WTRUs 102a, 102b, 102c are using. As an example, different network slices may be established for different use cases, such as services that rely on ultra-reliable low latency (URLLC) access, services that rely on enhanced large-scale mobile broadband (eMBB) access, and/or services for Machine Type Communication (MTC) access, among others. The AMF 182 may provide control plane functionality for switching between the RAN 113 and other RANs (not shown) that employ other radio technologies (e.g., LTE-A, LTE-a Pro, and/or non-3 GPP access technologies such as WiFi).

The SMFs 183a, 183b may be connected to the AMFs 182a, 182b in the CN 115 via an N11 interface. The SMFs 183a, 183b may also be connected to UPFs 184a, 184b in the CN 115 via an N4 interface. The SMFs 183a, 183b may select and control the UPFs 184a, 184b, and may configure traffic routing through the UPFs 184a, 184 b. SMFs 183a, 183b may perform other functions such as managing and assigning UE IP addresses, managing PDU sessions, controlling policy enforcement and QoS, and providing downlink data notification, among others. The PDU session type may be IP-based, non-IP-based, and ethernet-based, among others.

The UPFs 184a, 184b may connect 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 a packet-switched network (e.g., the internet 110) to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices, and the UPFs 184a, 184b may perform other functions, such as routing and forwarding packets, implementing user-plane policies, supporting multi-homed PDU sessions, processing user-plane QoS, buffering downlink packets, providing mobility anchoring processing, and so forth.

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 other networks 112, which may include other wired and/or wireless networks owned and/or operated by other service providers. In one embodiment, the WTRUs 102a, 102b, 102c may connect to the local Data Networks (DNs) 185a, 185b through the UPFs 184a, 184b via an N3 interface that interfaces to the UPFs 184a, 184b and an N6 interface between the UPFs 184a, 184b and the DNs 185a, 185 b.

In view of fig. 1A-1D and the corresponding description with respect to fig. 1A-1D, one or more or all of the functions described herein with respect to one or more of the following may be performed by one or more emulation devices (not shown): WTRUs 102a-d, base stations 114a-B, enode bs 160a-c, MME 162, SGW 164, PGW 166, gNB 180a-c, AMFs 182a-B, UPFs 184a-B, SMFs 183a-B, DNs 185a-B, and/or any other device(s) described herein. These emulation devices can be one or more devices configured to simulate one or more or all of the functions described herein. These emulation devices may be used, for example, to test other devices and/or to simulate network and/or WTRU functions.

The simulated device may be designed to conduct one or more tests with respect to other devices in a laboratory environment and/or in a carrier network environment. For example, the one or more simulated devices may perform one or more or all functions while implemented and/or deployed, in whole or in part, 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 can perform one or more or all functions while temporarily implemented/deployed as part of a wired and/or wireless communication network. The simulation device may be directly coupled to another device to perform testing and/or may perform testing using over-the-air wireless communication.

The one or more emulation devices can perform one or more functions, including all functions, while not being implemented/deployed as part of a wired and/or wireless communication network. For example, the simulation device may be used in a test scenario of a test laboratory and/or a wired and/or wireless communication network that is not deployed (e.g., tested) in order to conduct testing with respect to one or more components. The one or more simulation devices may be test devices. The simulation device may transmit and/or receive data using direct RF coupling and/or wireless communication via RF circuitry (e.g., the circuitry may include one or more antennas).

Techniques for selecting a feedback format to be used with sidelink communications are described. The WTRU may select either a sidelink unicast transmission or a sidelink multicast transmission to transmit data. The WTRU may select HARQ ACK/NACK feedback for feedback associated with the data transmission if the WTRU selects side link unicast to transmit data. The HARQ NACK feedback or HARQ ACK/NACK feedback may be selected for feedback based on one or more additional factors or conditions if the WTRU selects a sidelink multicast transmission to transmit the data. The WTRU may select HARQ NACK feedback or HARQ ACK/NACK feedback for the data transmission according to one or more of: a number of WTRUs receiving the data; a condition of a channel associated with transmitting the data; or a quality of service associated with transmitting the data. The WTRU may select the first or second PSFCH format to provide feedback related to transmitting the data based on one or more factors or conditions. The WTRU may select the first or second PSFCH format based on one or more of: the selected side link is unicast or side link multicast; selected HARQ NACK feedback or HARQ ACK/NACK feedback; or a quality of service associated with transmitting the data.

In connection with wireless communications (e.g., 3GPP), several deployment scenarios may be defined, such as indoor hotspots, dense cities, rural, urban macros, high speed, etc. On top of these deployment scenarios, three example use cases may be defined: enhanced mobile broadband (eMBB), large machine type communication (mMTC), and ultra-reliable and low latency communication (URLLC). Different use cases may focus on different requirements, such as higher data rates, higher spectral efficiency, low power and higher energy efficiency, lower latency and higher reliability.

Wireless communication provides for implementing vehicle-to-all (V2X) technology. Using the V2X technique, one or more of the following example operations may be performed: vehicle formation, sensor and state diagram sharing, remote driving, or automated collaborative driving.

Vehicle formation may include operating a group of vehicles in a tightly linked manner such that the vehicles move like a train (e.g., with virtual strings attached between the vehicles). For example, to maintain vehicle distance, vehicles may share status information between them. By using convoy, the distance between vehicles can be reduced and the number of drivers can be reduced. Queuing can reduce overall fuel consumption.

In the V2X communication, a vehicle congestion may occur. Vehicle congestion may result in a reduction in signal strength at, for example, high carrier frequencies (e.g., frequencies above 6 GHz). The vehicle obstruction may be treated as a separate condition, an out-of-sight condition, and a non-line-of-sight condition.

The V2X transmission mode may be selected. In LTE V2X, the vehicle may be in transmission mode 3 (e.g., mode 3 user) or transmission mode 4 (e.g., mode 4 user), for example. Mode 3 users may use resources allocated by the base station for Sidelink (SL) communications between vehicles or between vehicles and pedestrians. The mode 4 user may obtain a list of candidate resources allocated by the base station and may select a resource for SL communication for the mode 4 user among the candidate resources.

In NR V2X, mode 1 users may be similar to mode 3 users in LTE V2X, and mode 2 users may include mode 4 users in LTE V2X.

A "user" or "WTRU" may include a vehicle (e.g., a user).

V2X control information may be sent or received. Downlink Control Information (DCI) format 5A may be used. DCI Format 5A availableScheduling on a Physical Shared Control Channel (PSCCH), and one or more Sidelink Control Information (SCI) format 1 fields may be used for scheduling of the PSCCH. The payload of DCI format 5A may include one or more of: a carrier indicator, which may comprise one or more (e.g., 3) bits; e.g., the lowest index assigned to the subchannel for the initial transmission, which may comprise one or more (e.g.,) A bit; SCI format 1 field, e.g., frequency resource location of initial transmission and retransmission; a time gap between initial transmission and retransmission; SL index, which may comprise one or more (e.g., 2) bits (e.g., this field may be present for the case of Time Division Duplex (TDD) operation with uplink-downlink configurations 0-6). When a format 5A Cyclic Redundancy Check (CRC) may be scrambled with the SL semi-persistent scheduling vehicle RNTI SL-SPS-V-RNTI, there may be one or more of the following fields: a SL semi-persistent scheduling (SL SPS) configuration index, which may include one or more (e.g., 3) bits; 2) or an activate/release indication, which may include one or more (e.g., 1) bits.

If the number of information bits in format 5A that map to a given search space is less than the payload size of format 0 that maps to the same search space, zeros may be appended or padded to format 5A until the payload size (e.g., which is equal to the size of format 0 including any padding bits appended to format 0).

If format 5A CRC is scrambled by SL-V-RNTI and if the number of information bits in format 5A that are mapped to a given search space is less than the payload size of format 5A with CRC that is mapped to the same search space (where CRC is scrambled by SL-SPS-V-RNTI), and format 0 is not defined on the same search space, zeros may be appended to format 5A until the payload size is equal to the payload size of format 5A with CRC (where CRC is scrambled by SL-SPS-V-RNTI).

In a V2X implementation, SCI format 1 may be used. SCI format 1 may be used for scheduling of pschs.The payload of SCI format 1 may include one or more of the following: a priority, which may include one or more (e.g., 3) bits; a resource reservation, which may include one or more (e.g., 4) bits; e.g., frequency resource locations for initial transmissions and retransmissions, which may include one or more (e.g.,) A bit; for example, a time gap between initial transmission and retransmission, which may include one or more (e.g., 4) bits; a modulation and coding scheme, which may include one or more (e.g., 5) bits; or a retransmission index, which may comprise one or more (e.g., 1) bits. For example, reserved information bits may be added until the SCI format 1 size equals 32 bits. The reserved bits may be set to zero.

V2X mode 4WTRU resource selection may be performed. The resource selection for a mode 4WTRU (e.g., in LTE) may include one or more of the following. For example, by selecting an appropriate T based on latency requirements₁And T₂Value, n + T can be determined₁，n+T₂]Inter transmission window. The candidate resource may be represented by R_x，yAnd the candidate resource set may be represented by S. The set of candidate resources may be determined by sensing a side link Received Signal Strength Indication (RSSI). The total number of candidate resources may be referred to as M_total. For example, set S from S may be determined based on RSRP levels of candidate resources_A. If a candidate resource in S has an RSRP level above a certain threshold, the candidate resource may be saved to S_A. For example, if resource R_x，yConflicts with its own transmissions or other WTRU reserved resources (e.g., mode 3 reserved resources), then S may be selected from the candidate resource set_AIn which the resource R is removed_x，y. If S is_AIs not greater than 0.2M (e.g., after removing the conflicting resource) of the number of remaining candidate resources_totalThe set of candidate resources may be determined by sensing the sidelink RSSI with the smaller threshold. If S is_AIn (e.g., in removing conflicts)After resource) number of remaining candidate resources greater than 0.2M_totalThen set S_AMay be ranked based on the RSSI value of the resource averaged over the past several time slots. The first 0.2M of the lowest RSSI value may be assigned_totalRanked resources (e.g., S)_B) Reported to higher layers for final resource selection.

A Physical Uplink Control Channel (PUCCH) format may be selected and/or used. Uplink Control Information (UCI) may include HARQ-ACK, Scheduling Resources (SR), and Channel State Information (CSI) feedback. The UCI may be delivered, for example, via PUCCH. One or more (e.g., 5) PUCCH formats may be defined. One or more of the following may be applied. PUCCH format 0 and format 1 may be used to transmit 1-2 bits of payload, while PUCCH formats 2, 3, 4 may be used to transmit more than 2 bits of payload. PUCCH format 0 and format 2 may occupy 1 or 2 symbols, while PUCCH format 1, 3, 4 may occupy 4-14 symbols. PUCCH format 0 and format 2 may include (e.g., may be referred to as) a short PUCCH. PUCCH formats 1, 3, 4 may include (e.g., may be referred to as) a long PUCCH. PUCCH formats 0,1, 4 may occupy 1 Physical Resource Block (PRB), and PUCCH formats 2 and 3 may occupy 1-16 PRBs.

PUCCH format 0 may be based on 12 base sequences, e.g., base sequences with different cyclic shift values. In PUCCH format 0, payload information may be used to select a base sequence. A user may use two (2) sequences for a 1-bit payload and a user may use 4 sequences for a 2-bit payload. For example, user multiplexing may be supported to share a total of 12 base sequences.

PUCCH format 1 may be based on sequence modulation. Time domain Orthogonal Cover Codes (OCC) may be applied to the spread sequence modulation symbols (e.g., to achieve user multiplexing). The OCC sequence length may depend on the number of symbols of PUCCH format 1. The OCC sequence length may be equal to the number of OCC sequences (e.g., or the number of users used for multiplexing). In 4-14 symbols, for example, a demodulation reference signal (DMRS) may occur every other symbol.

PUCCH format 2 may be based on a cyclic prefix orthogonal frequency division multiplexing (CP-OFDM) waveform. The payload with CRC may be encoded using, for example, Reed-muller (rm) or polar codes. For example, the coded bits may be scrambled with a Gold sequence prior to Quadrature Phase Shift Keying (QPSK) modulation. The modulation symbols and DMRS may be FDM multiplexed (e.g., where DMRS occupies 1, 4, 7, 10 subcarriers of each PRB).

PUCCH formats 3 and 4 may be based on DFT-S-OFDM waveforms.

The PUCCH resource set, PUCCH resources and PUCCH format parameters may be configured (e.g., in system information block 1(SIB 1)) for common configuration and may be configured by, for example, a "PUCCH-configuration" Information Element (IE) for dedicated configuration.

Feedback techniques for V2X side link unicast and/or multicast may be performed. In V2X (e.g., LTE V2X), sidelink communications may be broadcast and no feedback may be performed. In the V2X example (e.g., NR V2X), the sidelinks may be unicast or multicast, and feedback may be performed, e.g., to provide more reliable transmission and/or achieve higher spectral efficiency for a given channel condition. The feedback may include HARQ-ACK information, CQI, MIMO-related parameters (e.g., PMI, RI, CRI), and the like.

In the V2X example (e.g., NRV2X), a Physical Sidelink Feedback Channel (PSFCH) may be defined. The PSFCH may be supported to transmit side link feedback control information (SFCI) for unicast and/or multicast via the PSFCH.

The PSFCH format and implementation may be designed. The PSFCH format may be aligned between a transmit (Tx) WTRU and a receive (Rx) WTRU. The PSFCH format may be known to other WTRUs (e.g., mode 2 WTRUs) to facilitate their resource selection for the PSFCH. The PSFCH format (e.g., and PSFCH format parameters) may be determined and signaled. For the multicast side link, the sharing mechanism of feedback resources between group members and the PSFCH format determination may be considered.

The SFCI may be delivered over the PSFCH and PSSCH. Piggybacking of SFCI on PSFCH may be performed.

Resource allocation for mode 1WTRU retransmissions for V2X sidelink (e.g., unicast or multicast) may be performed. Side link unicast or multicast may support HARQ feedback that may trigger a retransmission on the side link unicast or multicast. For example, resources for retransmission may be allocated by the gNB. The Tx WTRU may request retransmission resources based on feedback from the Rx WTRU and other factors. The Rx WTRU may send the HARQ feedback to the gNB, which may trigger a retransmission resource allocation.

The gNB may schedule side link communications (e.g., in LTE). The gNB may schedule LTE sidelink transmissions, which may be useful in certain deployment areas covered by the gNB signals. When an LTE eNB is removed due to coverage by, for example, a gNB configured to schedule sidelink transmissions may be useful.

In URLLC (e.g., NR enhanced URLLC), compact DCI may be employed. The compact DCI may limit the payload size of the DCIs 1_0 and 0_0, e.g., such that a payload size of about 24 bits may be used for the compact DCI. The payload size of the LTE DCI 5A format may be compact (e.g., such that the new NR DCI format has a similar size as the compact DCI), which may reduce blind detection effort. The compact format of LTE DCI 5A may be designed.

A PSFCH structure may be provided. The subset of PUCCH formats may be reused for the PSFCH format. The Tx WTRU may determine the PSFCH format/resource and indicate the PSFCH format/resource (e.g., in the SCI). For example, the Tx WTRU may indicate one or more of the following (e.g., in SCI): the PSFCH format(s) and/or its associated parameters; PSFCH format usage associated with SL traffic type (e.g., unicast or multicast); psch to HARQ feedback slot offset (e.g., a direct indication thereof); or a "HARQ-NACK" scheme or a "HARQ-ACK/NACK" scheme (e.g., for multicast SL) (e.g., for selection thereof).

The PSFCH structure and/or use may be provided where one or more of the following may apply. A subset of PUCCH formats may be reused for the PSFCH format. The Tx WTRU may determine (e.g., dynamically determine) the PSFCH format/resource and/or provide an indication in the SCI. A PFSCH format 0 design may be provided and/or used. A PFSCH format 1 design may be provided and/or used. A PSFCH format 2 design may be provided and/or used.

A subset of PUCCH formats may be used (e.g., reused) for the PSFCH format. The payload in PSFCH format may include HARQ-ACK, CSI, and/or reference signal received power/reference signal received quality (RSRP/RSRQ). The HARQ-ACK bits may be based on non-code block groups (non-CBGs) (e.g., where 1 or 2 HARQ-ACK feedback bits may be supported). The HARQ-ACK bits may be CBG based (e.g., where the number of HARQ-ACK feedback bits may be greater than 2). The CSI may include, for example, CQI/PMI/RI. In an example, the SR may not be included in the PSFCH (e.g., unlike the NR PUCCH).

The payload of the PSFCH may comprise 1-2 bits for HARQ-ACK. The payload of the PSFCH may comprise more than 2 bits for CSI or RSRP/RSRQ (e.g., with or without HARQ-ACK). The waveform of the SL control and data channels may be (e.g., may be only) CP-OFDM. The waveform of the SL control and data channels may also be DFT-s-OFDM. PUCCH formats 3 and 4 may not fit into the PSFCH format.

A subset of the PUCCH formats may be used (e.g., reused) for the PSFCH format. The PSFCH format 0 may be defined in a similar manner to the PUCCH format 0. The PSFCH format 1 may be defined in a similar manner to the PUCCH format 1. The PSFCH format 2 may be defined in a similar manner to PUCCH format 2. PSFCH formats 0,1, 2 may be defined similarly to PUCCH formats 0,1, 2, respectively.

The PSFCH format 0 may be defined in a similar manner to the PUCCH format 0. The PSFCH format 1 may be defined in a similar manner to the PUCCH format 2. When PSFCH formats 0 and 1 are defined (e.g., only PSFCH formats 0 and 1 are defined), PSFCH formats 0 and 1 may be defined similarly to PUCCH formats 0 and 2, respectively.

The Tx WTRU may determine (e.g., dynamically determine) the PSFCH format/resource. The TX WTRU may indicate the PSFCH format/resource, for example, in the SCI.

The device (e.g., the gNB) may apply RRC messages, e.g., to configure one or more (e.g., up to 4) PUCCH resource sets. These resource sets (e.g., each resource set) may include one or more (e.g., several) PUCCH resources. The PUCCH resources (e.g., each PUCCH resource) may be associated with, for example, a PUCCH format, where frequency domain (F-domain) and time domain (T-domain) (e.g., within a slot) Resource Elements (REs) may be specified in a resource configuration.

The device (e.g., the gNB) may indicate to the WTRU one or more of the following: a slot that the WTRU may use to transmit the PUCCH (e.g., where such indication may be via a DCI field, e.g., "PDSCH-to-HARQ feedback timing indicator"); or PUCCH resources that the WTRU may use to transmit the PUCCH (e.g., where such an indication may be via a DCI field, such as a "PUCCH resource indicator").

The WTRU may determine a set of resources to use, for example, based on the UCI payload size. The WTRU may determine resources within the set of resources, for example, based on the DCI.

In V2X SL (e.g., NR V2X SL), RRC configuration between Tx WTRU and Rx WTRU may not be appropriate, may not be used, etc. One or more of the following may be applied. The RRC configuration may not meet the latency requirements of the V2X side chain data. Other WTRUs (e.g., other mode 2 WTRUs) may not know the RRC configuration. Other WTRUs (e.g., other mode 2 WTRUs) may collect PSFCH information via sensing implementations and may schedule their own transmissions, which may involve reserving one or more PSFCH resources.

The Tx WTRU may use the SCI to indicate (e.g., dynamically inform) the Rx WTRU about the feedback information. The feedback information may include one or more of: a PSFCH enable or disable indicator; the PSFCH format and its associated parameters; PSSCH to HARQ _ feedback timing indicator; or an indication of an option for a "HARQ-NACK" scheme or an option for a "HARQ-ACK/NACK" scheme (e.g., for multicast SL).

One or more of the following may apply to using SCI to indicate the PSFCH format and/or associated parameters. A PSFCH format to be used, such as PSFCH format 0,1 or 2, may be provided. A starting PRB (e.g., or subchannel) of the PSFCH resource may be provided. If PSFCH format 2 is used, the number of PRBs may be provided. The number of symbols within a slot and the starting symbol index may be provided. An indication may be provided as to whether intra-slot frequency hopping is supported. If intra-slot frequency hopping is supported, a starting PRB (e.g., or subchannel) for one hop (e.g., the second hop) may be provided. The PSFCH format usage may be associated with SL traffic type (e.g., unicast or multicast). For SL multicast, if CSI or RSRP/RSRQ feedback is not sent and CBG case is not supported, then PSFCH format 0 or 1 may be used (e.g., only PSFCH format 0 or 1). For SL unicast, either PSFCH formats 0 and 2 (e.g., PSFCH formats 0 and 2 only), or PSFCH formats 1 and 2 (e.g., PSFCH formats 1 and 2 only) may be used.

The PDSCH to HARQ feedback timing indicator may be provided using SCI. One or more of the following may be applied. The PDSCH to HARQ feedback timing indicator (e.g., 3-bit PDSCH to HARQ feedback timing indicator field in DCI) may be equal to an entry index of the "dl-DataToUL-ACK" table. For example, the "dl-Data-ToUL-ACK" table may be configured in a "PUCCH-Config" IE via an RRC message. The slot offset value may be used to send HARQ-ACK feedback (e.g., an offset from the slot receiving the PDCCH). The slot offset (e.g., maximum slot offset) may include 15 slots. An indication (e.g., a direct indication) of the psch to HARQ feedback slot offset may be provided. In V2X SI (e.g., NR V2X SI), a value in "pscch to HARQ feedback timing indicator" may indicate (e.g., directly indicate) a slot offset value that HARQ feedback receives from the pscch (e.g., rather than relying on RRC parameters to determine the actual slot offset). The indication (e.g., the direct indication) may provide the timing offset to other WTRUs (e.g., other mode 2 WTRUs) (e.g., through SCI decoding in other WTRU sensing implementations). This helps to avoid collisions on the PSFCH (or HARQ) resources.

A 3-bit field may be provided and one or more of the following may apply: "000" may indicate that the offset is equal to 0, e.g., the same slot is used for HARQ feedback; "001" may indicate an offset of 1 slot; "010" may denote an offset of 2 slots; "011" can indicate an offset of 3 slots; "100" may indicate an offset of 4 slots; "101" may indicate an offset of 5 slots; "110" may indicate an offset of 6 slots; or "111" may indicate an offset of 7 slots. Similar techniques can be extended to 4-bit fields.

The feedback information provided using the SCI may include an indication of a "HARQ-NACK" scheme or a "HARQ-ACK/NACK" scheme (e.g., for a multicast side link). One or more of the following may be applied. If the number of receiver WTRUs is large, a "HARQ-NACK" scheme may be used. When the number of receiver WTRUs is small and the PSFCH resources may be shared by the receiver WTRUs, a "HARQ-ACK/NACK" scheme may be used. The Tx WTRU may select a scheme between "HARQ-NACK" schemes or "HARQ-ACK/NACK" schemes and indicate a feedback operation to the Rx WTRU. If the "HARQ-ACK/NACK" scheme is selected, an indication (e.g., SCI indication) may be provided (e.g., by the Tx WTRU) as to whether additional criteria are present in deciding the HARQ-ACK/NACK transmission. The Rx WTRU may stop transmitting the ACK bit if the Rx WTRU previously sent an ACK for the same TB. The Rx WTRU may continue to transmit the ACK bit each time the Rx WTRU receives the PSSCH and the Rx WTRU's transmission TB has been decoded (e.g., whether the TB was decoded in a previous (re-) transmission or a current (re-) transmission).

If the PSFCH resource/format indication is included in the SCI, the PSFCH resource/format may be broadcast to one or more WTRUs (e.g., all WTRUs, such that the non-targeted WTRUs do not use the reserved PSFCH resources). If a two-level (e.g., or two-part) SCI scheme is used, the PSFCH resource/format indication may be included in part 1 of the SCI (e.g., along with other PSCCH/PSCCH resource indications). Part 1 of the SCI may be broadcast to WTRUs (e.g., all WTRUs), for example, without RNTI-based scrambling.

A PSFCH format 0 design may be provided. The initial cyclic shift value may be included in the SCI. CDM sharing may be performed. The initial cyclic shift value may depend on the WTRU ID. FDM sharing may be performed. The location of the PRB may depend on the WTRU ID. A PSFCH format 0 for HARQ-NACK scheme in sidelink multicast may be provided.

A PFSCH format 0 design may be provided. An indication (e.g., a dynamic indication) of the initial cyclic shift value may be provided. One or more of the following may be applied. PUCCH format 0 may support user multiplexing on the same PUCCH resource (e.g., in NR). One or more (e.g., 12 sequences) may be used for PUCCH format 0. If a WTRU (e.g., each WTRU) sends a single bit HARQ-ACK/NACK feedback, the WTRU may use two (2) sequences and the resource may be shared by one or more WTRUs (e.g., 6 WTRUs). If a WTRU (e.g., each WTRU) sends two bits of HARQ-ACK/NACK feedback, the WTRU may use 4 sequences and the resources may be shared by one or more WTRUs (e.g., 3 WTRUs). The WTRU (e.g., each WTRU) may use a different initial cyclic shift value. The initial cyclic shift value may be signaled, e.g., via RRC configuration, and may be associated with a PUCCH resource.

The initial cyclic shift value of PSFCH format 0 may be indicated (e.g., dynamically indicated), which may not be dependent on PSFCH resources.

The PSFCH format 0 resources may be shared, for example, among one or more (e.g., multiple) SL sessions.

The initial cyclic shift value may be included in the SCI. One or more of the following may be applied. The PSFCH format 0 resource may be shared, for example, among multiple sidelink sessions. In V2X (e.g., NR V2X) sidelink transmission, the initial cyclic shift value for PSFCH format 0 may be indicated in SCI. A WTRU (e.g., another mode 2WTRU performing sensing) may detect the initial cyclic shift value of PSFCH format 0. A WTRU (e.g., another mode 2WTRU) may refrain from using the same initial cyclic shift value of PSFCH format 0 if, for example, the WTRU determines to allocate PSFCH feedback on a resource (e.g., the same resource).

The PSFCH format 0 resources may be shared among WTRUs (e.g., different WTRUs) of a SL session (e.g., sidelink multicast).

Code Division Multiplexing (CDM) sharing may be performed. The initial cyclic shift value may depend on, for example, the WTRU ID. One or more of the following may be applied. The PSFCH format 0 resource may be used for sidelink sessions. The PSFCH format 0 resource may be shared by multiple Rx WTRUs in sidelink multicast. In an example, different Rx WTRUs may use different initial cyclic shift values when using the same PSFCH format 0 resource. The initial cyclic shift value used by the WTRY may depend on the ID of the Rx WTRU (e.g., RNTI, group member ID, etc.) and the ID of the Tx WTRU (e.g., RNTI, group member ID, etc.).

In an example, a group of 4 WTRUs may include group member IDs (e.g., ID1, ID2, ID3, ID 4). The Tx WTRU with ID1 may send pscch data to Rx WTRUs with ID2, ID3, and ID4, respectively. The Rx WTRU with ID2 may calculate the difference between its own ID and the Tx WTRU ID. The Rx WTRU with ID2 may determine the initial cyclic shift value. In an example, an Rx WTRU with ID2 may set its initial cyclic shift value to m₀ID1-ID2 mod 3. Rx WTRUs with ID3 or ID4 may set their initial cyclic shift values to m, respectively₀| ID1-ID3| mod 3 and m₀＝|ID1-ID4|mod 3。

FDM sharing may be performed. The location of the PRB may depend on the ID of the WTRU. One or more of the following may be applied. For sidelink multicast, different WTRUs may use different portions of the PSFCH resources. If PSFCH format 0 is used, the HARQ-ACK/NACK feedback for a WTRU (e.g., for each WTRU) may occupy 1 or 2 symbols of 1 PRB. Different WTRUs in a sidelink multicast may use different PRBs of a large PSFCH resource. The choice of different PRBs for the large PSFCH resource may depend on the group member ID or the RNTI of the WTRU. Fig. 2 illustrates exemplary sharing of PSFCH resources (e.g., FDM sharing) by multiple Rx WTRUs in sidelink multicast.

The PSFCH format 0 resources may not be shared (e.g., between multiple WTRUs). One or more of the following may be applied. The PSFCH format 0 resources may be used for Rx WTRUs (e.g., a single Rx WTRU). PSFCH format 0 resource sharing may not be performed. For example, the initial cyclic shift value of PSFCH format 0 may be indicated in the SCI so that the Rx WTRU may know the initial cyclic shift value of PSFCH format 0. The Rx WTRU may set the initial cyclic shift value to, for example, the difference between the ID of the Tx WTRU and the ID of the Rx WTRU.

A PSFCH format 0 for HARQ-NACK scheme in sidelink multicast may be provided.

A HARQ-NACK scheme (e.g., for sidelink multicast) may be used. In an example, for PSFCH format 0 supporting HARQ-NACK scheme, a sequence (e.g., Gold sequence with a specific cyclic shift value, e.g., m) may be used_cs0) to indicate HARQ-NACK. If different sidelink multicasts use different initial cyclic shift values (e.g., as shown in SCI), the PSFCH resources (e.g., the same PSFCH resources) may be shared among multiple sidelink sessions.

A single TB may be transmitted and a single HARQ-NACK may be generated. If two TBs are transmitted, the result scenarios that can be fed back include the following (e.g., depending on whether a TB is received or not). TB1 and TB2 may be received. TB1 may be received and TB2 may not be received. TB1 may not be received and TB2 may be received. TB1 and TB2 may not be received. For example, if none of the TBs are successfully decoded, the Rx WTRU may indicate a combined NACK using a single sequence (e.g., Gold sequence with unique cyclic shift value). The Rx WTRU may process two TBs separately. The Rx WTRU may use one or more sequences (e.g., three different sequences), such as Gold sequences with three different cyclic shift values.

For example, if any of the TBs is not successfully decoded, the Rx WTRU may indicate a combined NACK using a single sequence (e.g., a Gold sequence with a unique cyclic shift value). The sequence amplitude scaling factor may be different, for example, to indicate whether one TB is not decoded correctly or whether both TBs are not decoded correctly. The sequence amplitude scaling factor may be smaller if a single TB is not decoded correctly. The sequence amplitude scaling factor may be large if neither TB is decoded correctly. For example, if a Tx WTRU receives a NACK (e.g., the combined NACK), the Tx WTRU may retransmit the TB.

The Rx WTRU may use three different sequences (e.g., Gold sequences with three different cyclic shift values) to indicate one or more of the following: the first TB (for example,only the first TB) is not decoded correctly; the second TB (e.g., only the second TB) is not decoded correctly; or both TBs are not decoded correctly. In the examples: having a cyclic shift value m_csA Gold sequence of 0 may be used to indicate that the first TB is not decoded correctly; having a cyclic shift value m_csA Gold sequence of 4 may be used to indicate that the second TB is not decoded correctly; and has a cyclic shift value m_csA Gold sequence of 8 may be used to indicate that the two TBs are not decoded correctly. If the Tx WTRU detects m with a cyclic shift value_csGold sequence of 8, or if Tx WTRU detects m_cs0 and m_csThe Tx WTRU may retransmit TBs (e.g., two TBs) for two Gold sequences of 4. If the Tx WTRU detects (e.g., detects only) a cyclic shift value m_csThe Tx WTRU may retransmit (e.g., may retransmit only) the first TB for a Gold sequence of 0. If the Tx WTRU detects (e.g., detects only) a cyclic shift value m_csThe Tx WTRU may retransmit (e.g., may retransmit only) the second TB, for example, for a Gold sequence of 4.

The Rx WTRU may treat TBs (e.g., two TBs) separately. The Rx WTRU may use a sequence (e.g., Gold sequence with unique cyclic shift value) to indicate NACK for TBs (e.g., for each TB). A sequence corresponding to the first TB may be mapped in the first PSFCH resource and a sequence corresponding to the second TB may be mapped in the second PSFCH resource. The first PSFCH resource may be TDM or FDM multiplexed. In the case of TDM multiplexing, one or more of the following may be applied. The symbol (e.g., the first symbol of the PSFCH resource) may comprise a sequence corresponding to the first TB. The symbol (e.g., a second symbol of the PSFCH resource) may comprise a sequence corresponding to a second TB. In the FDM multiplexing scheme, one or more of the following may be applied. The PRB (e.g., the first PRB of the PSFCH resource) may include a sequence corresponding to the first TB. The PRB (e.g., the second PRB of the PSFCH resource) may include a sequence corresponding to the second TB. The Rx WTRU (e.g., each Rx WTRU) may insert the first and/or second sequences into the first and/or second PSFCH resources (e.g., the appropriate PSFCH resources, depending on the decoding result). If the Tx WTRU detects the sequence in the appropriate PSFCH resource(s), the Tx WTRU may determine whether to retransmit the TBs (e.g., to retransmit zero, one, or two TBs).

A PSFCH format 1 design may be provided. An indication of the initial cyclic shift value and OCC index may be provided (e.g., in the SCI). The initial cyclic shift value and/or OCC sequence index may depend on the WTRU ID.

A PFSCH format 1 design may be provided. An indication (e.g., a dynamic indication) of the initial cyclic shift value and/or the OCC index may be provided. PUCCH format 1 may support user multiplexing on the same PUCCH resource (e.g., in NR). A PUCCH resource (e.g., each PUCCH resource associated with PUCCH format 1) may be configured with an initial cyclic shift value. For example, WTRUs may share a common PUCCH format 1 resource by using different OCC sequences for spreading. One or more (e.g., up to 7) OCC sequences may be used for PUCCH format 1 with 14 symbols. If up to 7 OCC sequences are used for PUCCH format 1 with 14 symbols, PUCCH format 1 resources may be shared by up to 7 WTRUs.

The initial cyclic shift value and OCC index of the PSFCH format 1 may be indicated (e.g., dynamically indicated), which may not be dependent on the PSFCH resources.

PSFCH format 1 resource sharing between multiple SL sessions may be provided.

The initial cyclic shift value and/or OCC index may be included in the SCI. A PSFCH format 0 resource (e.g., the same PSFCH format 0 resource) may be shared among multiple sidelink sessions. In V2X (e.g., NR V2X) sidelink transmission, the initial cyclic shift value and/or OCC index for PSFCH format 1 may be indicated in SCI. A WTRU performing sensing (e.g., another mode 2WTRU) may detect the initial cyclic shift value and/or OCC index. For example, if a WTRU (e.g., other mode 2WTRU) determines to allocate PSFCH feedback on the same resource, the WTRU may not use the same initial cyclic shift value and/or OCC index for PSFCH format 1.

PSFCH format 1 resource sharing between WTRUs of a SL session (e.g., a single SL session) may be provided.

The initial cyclic shift value and/or OCC sequence index may depend on the ID of the WTRU. The PSFCH format 1 resource may be used for sidelink sessions. The PSFCH format 1 resource may be shared by one or more Rx WTRUs in sidelink multicast. For example, if the same PSFCH format 1 resource is used, the Rx WTRU may use different initial cyclic shift values and/or OCC sequences. The initial cyclic shift value and/or OCC sequence used by the WTRU may depend on the ID of the Rx WTRU (e.g., RNTI, group member ID, etc.) and the ID of the Tx WTRU (e.g., RNTI, group member ID, etc.).

In an example, with an ID₀The Tx WTRU of (2) may send pscch data to the Rx WTRU. With ID_iThe ith Rx WTRU of (a) may calculate the difference between its own ID and the ID of the Tx WTRU. One or more of the following may be applied. With ID_iThe ith Rx WTRU of (a) may determine the initial cyclic shift value as m₀＝|ID₀-ID_iL mod 12. The ith Rx WTRU may determine the OCC sequence index as i ═ ID₀-ID_iL mod 7. The ith Rx WTRU may determine an initial cyclic shift value and an OCC sequence index based on a difference between its own ID and the ID of the Tx WTRU. One or more (e.g., 12) initial cyclic shift values and one or more (e.g., 7) OCC sequences may be used. One or more (e.g., 84) combinations of initial cyclic shift values and OCC sequences may be used.

The PSFCH format 1 resource may not be shared by multiple WTRUs.

The PSFCH format 1 resources may be used for Rx WTRUs. PSFCH format 1 resource sharing may not be performed. One or more of the following may be applied. The initial cyclic shift value and/or OCC sequence index for PSFCH format 1 may be indicated in the SCI so that, for example, the Rx WTRU may know the initial cyclic shift value and/or OCC sequence index. The Rx WTRU may set an initial cyclic shift value and/or an OCC sequence index according to a difference between the ID of the Tx WTRU and the ID of the Rx WTRU.

A PSFCH format 2 design may be provided. The number of PRBs used for PSFCH format 2 resources may be indicated in the SCI. The SFCI code rate may be indicated in the SCI. The WTRU ID may be embedded for PSFCH format 2. The Tx WTRU may select the PSFCH format 0 resources and/or the PSFCH format 1 resources. The Rx WTRU may select the PSFCH format 2 resource.

A PSFCH format 2 design may be provided. PSFCH format 2 may be used to send HARQ-ACK/NACK bits, side-link CSI (e.g., including CQI, PMI, RI, etc.), and/or side-link RSRP/RSRQ for CBG-based transmissions. The techniques described herein may be used to send HARQ-ACK/NACK bits and side link CSI. Similar techniques may be applied to perform RSRP/RSRQ feedback.

SFCI payloads may be concatenated, for example, by placing HARQ-ACK/NACK bits before side link CSI bits. For example, according to the SFCI payload size, segmentation processing may be applied. A CRC (e.g., a 6-bit 11-bit CRC) may be attached to the segments (e.g., each segment). For example, a segment may not be appended with a CRC depending on the size of the segment. In an example, if the payload size is below 12 bits, no CRC may be appended and a code (e.g., Reed Muller code) may be used. If the payload size is between 12 bits and 19 bits, a 6-bit CRC may be appended and polarity coding may be applied. If the payload size is above 19 bits, an 11-bit CRC may be appended and polarity coding may be applied.

The number of PRBs of the PSFCH format 2 resource may be indicated in the SCI.

The number of PRBs for PSFCH format 2 may be indicated in the SCI, e.g., by the Tx WTRU. The Tx WTRU may perform sensing and may select PSFCH resources for the Rx WTRU.

The Rx WTRU may select the code rate r, e.g., from a list of possible code rate values_minSo that the selected code rate r_minIs the minimum of the possible values that satisfy the following condition:

the number of PRBs indicated in the SCI may be indicated (e.g., between 1 and 16).The number of subcarriers (e.g., 8) in the PRB carrying the SFCI information may be indicated.The number of OFDM symbols (e.g., 1 or 2) in the PSFCH format 2 indicated in the SCI may be indicated. Q_mThe modulation order of PSFCH format 2 may be indicated (e.g., QPSK ═ 2). SFCI_sizeSFCI payload size may be indicated. A list of possible values of the code rate r may be specified or configured (e.g., pre-specified or pre-configured). In an example, the list of possible values of the code rate r may include: 0.08,0.15,0.25,0.35,0.45,0.6,0.8.

The Tx WTRU may determine the number of PRBs for the PSFCH format 2 resource, e.g., based on one or more of: quality of service (QoS) of the data, sensing of the PSFCH resources, number of group members, etc. The Tx WTRU may select a number of PRBs (e.g., a large number) so that the feedback may provide coding gain for reliable transmission (e.g., for high reliability data). The Tx WTRU may select a small number of PRBs (e.g., for low reliability data).

The SFCI code rate may be indicated in the SCI.

The Tx WTRU may indicate the code rate of the SFCI in the SCI. If the code rate of the SFCI is indicated in the SCI, the number of PRBs for the PSFCH format 2 may or may not be indicated in the SCI. The number of PRBs for PSFCH format 2 may be indicated in the SCI if, for example, the Tx WTRU performs sensing and selects PSFCH format 2 resources for the Rx WTRU. If the Rx WTRU performs sensing and selects the PSFCH format 2 resource, the number of PRBs for PSFCH format 2 may not be indicated in the SCI.

The Tx WTRU may select the SFCI code rate based on the data QoS and the sensing result on the PSFCH resource. A small code rate may be selected (e.g., for high reliability data). A large code (e.g., for low reliability data) may be selected.

Rx WT if SFCI code rate is provided in SCI and no number of PRBs for PSFCH Format 2 is indicated in SCIAn RU may determine the number of PRBs for PSFCH format 2 (e.g., between 1 and 16). The number of PRBs for PSFCH format 2 may be determined asThe minimum number may be between 1 and 16, such that:

one or more of the following may be applied.The number of subcarriers (e.g., 8) in the PRB carrying the SFCI information may be indicated.The number of OFDM symbols (e.g., 1 or 2) in the PSFCH format 2 indicated in the SCI may be indicated. Q_mThe modulation order of PSFCH format 2 may be indicated (e.g., QPSK ═ 2). r may indicate the SFCI code rate indicated in the SCI. SFCI_sizeThe SFCI payload size may be indicated.

The maximum allowable SFCI payload size (e.g., including CRC) carried in PSFCH format 2 may be derived by 16 × 8 × 2 × 0.8 ═ 409, where the selected maximum code rate may include 0.8 and the number of OFDM symbols may include 2. If the SFCI payload is greater than a threshold (e.g., 409 bits), filtering may be applied between CSI reports.

The WTRU ID may be embedded for PSFCH format 2.

The Rx WTRU may not include the WTRU ID in the feedback if the Tx WTRU reserves PSFCH format 2 resources for the Rx WTRU. If the Rx WTRU reserves PSFCH format 2 resources, the Rx WTRU may include its ID in the feedback (e.g., for multicast sidelink), which may allow the Tx WTRU to know which Rx WTRU sent the feedback, and may avoid confusion if the Tx WTRU supports multiple sessions simultaneously (e.g., sidelink unicast or multicast sessions).

The ID of the Rx WTRU may be included in the feedback. One or more of the following may be applied. The Rx WTRU may set its ID as part of the payload of the SFCI, which may be transmitted with the HARQ-ACK/NACK and/or sidelink CSI bits. The ID of the Rx WTRU may be placed before the HARQ-ACK/NACK bits and the sidelink CSI bits. Part or all of the ID of the Rx WTRU may be used to mask the CRC of the SFCI. If the SFCI payload is greater than 12 bits, a CRC (e.g., 6 or 11 bit CRC) may be generated prior to polarity encoding of the SFCI. One or more bits (e.g., 6 or 11 bits) may be generated from the ID of the Rx WTRU, for example, to mask the CRC of the SFCI. The ID of the Rx WTRU may be used to generate a scrambling sequence that may be used to scramble the polarity-coded and rate-matched bits from the SFCI. The scrambling sequence includes, for example, a length-31 Gold sequence with an initial value based on the ID of the Rx WTRU and/or the ID of the Tx WTRU. The initialization value of the PSFCH scrambling sequence may be a function of the ID of the Rx WTRU and/or the ID of the Tx WTRU, and may be set to:

C_init＝ID_Rx·2^A+ID_Tx，

one or more of the following may be applied. ID_RxThe ID of the Rx WTRU may be indicated. ID_TxThe ID of the Tx WTRU may be indicated. The value may include 15 or may depend on the length of the ID of the Tx WTRU.

The Tx WTRU may select the PSFCH format 0 resources and/or the PSFCH format 1 resources. The Rx WTRU may select the PSFCH format 2 resource.

PSFCH format 0 and format 1 may support user multiplexing on the same resource. PSFCH format 2 may not support user reuse on the same resource. The Tx WTRU may select common PSFCH format 0 resources and/or format 1 resources to share for one or more Rx WTRUs (e.g., in sidelink multicast). The location of the PSFCH format 0 or format 1 resource may be indicated. For PSFCH format 2 resources, the Rx WTRU may select its own resources to send the SFCI. The Tx WTRU may not reserve PSFCH format 2 resources for the Rx WTRUs (e.g., every Rx WTRU). The PSFCH format 0 resource may be used for sidelink unicast and the PSFCH format 1 resource may be used for sidelink multicast (e.g., due to its ability to support more WTRUs sharing the same PSFCH format 1 resource).

One or more techniques associated with the PSFCH may be provided. The Tx WTRU may determine the HARQ feedback scheme and the PFSCH format. The Tx WTRU may perform sensing in consideration of the PFSCH. The Rx WTRU may receive a transmission (e.g., unicast or multicast) on the psch and may prepare HARQ feedback.

The WTRU may select a feedback format to be used with sidelink communication. The WTRU may choose to transmit data using either sidelink unicast transmission or sidelink multicast transmission. Depending on the selected transmission type and one or more additional factors, the WTRU may choose to use HARQ ACK/NACK or HARQ NACK feedback related to transmitting the data. The WTRU may also choose to use either PSFCH format 0 or PSFCH format 1 for feedback depending on whether unicast or multicast communication is used and one or more additional factors.

The Tx WTRU may determine the HARQ feedback scheme. If the HARQ feedback scheme is enabled, the Tx WTRU may determine the HARQ feedback scheme and the PSFCH format, e.g., based on a number of criteria, such as the number of Rx WTRUs, the SFCI payload, etc.

Fig. 3 shows an example implementation associated with Tx WTRU selection of HARQ feedback scheme and PSFCH format. The WTRU may receive data to be sent over the psch. The WTRU may receive instructions from higher layers, e.g., for determining whether HARQ feedback may be used for transmission. The WTRU may determine whether to perform HARQ feedback based on, for example, QoS characteristics of the data, the number of Rx WTRUs, or network congestion. If no feedback is performed, the WTRU may set a "PSFCH disable indicator" in, for example, the SCI. If feedback is performed, the WTRU may set a "PSFCH enable indicator" in, for example, the SCI.

The WTRU may select between the PSFCH format and the HARQ feedback scheme. As shown in fig. 3, if data is used for unicast sidelink transmission, a HARQ-ACK/NACK scheme may be used. One or more of the following may be applied. For example, the non-CBG based HARQ-ACK/NACK bit(s) may be independently transmitted using either PSFCH format 0 or format 1. HARQ-ACK/NACK bit(s) may be transmitted with CSI feedback using PSFCH format 2. Alternatively, the CBG-based HARQ-ACK/NACK bits may be transmitted using PSFCH format 2.

The non-CBG based HARQ-ACK/NACK bit(s) may be independently transmitted using either PSFCH format 0 or format 1. One or more of the following may be applied. The choice between different PSFCH formats (e.g., PSFCH format 0 and format 1) may depend on, for example, the channel busy ratio. PSFCH format 0 may be selected for high channel busy ratios (e.g., because PSFCH format 0 may include 1 or 2 symbols). PSFCH format 1 may be selected for low channel busy ratios (e.g., because PSFCH format 1 may include 4-14 symbols). The choice between different PSFCH formats (e.g., PSFCH format 0 and format 1) may depend on the sensing result on the PSFCH resource. If more than 4 OFDM symbols are available on the resource, format 1 may be used. If more than 4 OFDM symbols are not available on the resource, then PSFCH format 0 may be used. The choice between PSFCH format 0 and format 1 may depend on the QoS characteristics or requirements of the data, such as reliability or minimum communication range. For data with high reliability and a large minimum communication range, for example, the PSFCH format 1 may be selected. For data that does not have high reliability or a large minimum communication range, format 0 may be selected.

The HARQ-ACK/NACK bit(s) may be transmitted using PSFCH format 2 (e.g., along with CSI feedback). The CBG-based HARQ-ACK/NACK bits may be transmitted using PSFCH format 2.

As shown in fig. 3, if data is associated with multicast, a HARQ-ACK/NACK scheme or a HARQ-NACK scheme may be used. The selection between the HARQ-ACK/NACK scheme and the HARQ-NACK scheme may depend on at least one or more of the following: number of Rx WTRUs, channel congestion status, or data QoS characteristics or requirements.

The number of Rx WTRUs may be used to select between the HARQ-ACK/NACK scheme and the HARQ-NACK scheme. One or more of the following may be applied. For a small number of Rx WTRUs (e.g., less than Thres1), a HARQ-ACK/NACK scheme may be used. For multiple (e.g., large number) Rx WTRUs (e.g., greater than or equal to Thres1), a HARQ-NACK scheme may be used. If the number of Rx WTRUs is unknown to the Tx WTRU, a HARQ-NACK scheme may be used.

The channel congestion status may be used to select between the HARQ-ACK/NACK scheme and the HARQ-NACK scheme. One or more of the following may be applied. For high-load channel conditions, a HARQ-NACK scheme may be used (e.g., to save feedback resources). For low-load channel conditions, a HARQ-ACK/NACK scheme may be used.

The data QoS characteristic may be used to select between the HARQ-ACK/NACK scheme and the HARQ-NACK scheme. One or more of the following may be applied. For high reliability data, a HARQ-ACK/NACK scheme may be used (e.g., it may be applied in the HARQ-NACK scheme since the HARQ-ACK/NACK scheme may avoid DTX problems). For non-high reliability data, a HARQ-NACK scheme may be used. For delay critical data, for example, a HARQ-ACK/NACK scheme may be used. For non-delay critical data, a HARQ-NACK scheme may be used.

If a HARQ-NACK scheme is used, then PSFCH format 0 (e.g., default) may be used, where a sequence (e.g., a fixed or (pre) configured sequence) may be used to indicate NACK.

If a HARQ-ACK/NACK scheme is used, the choice between different PSFCH formats, e.g. format 0 and format 1, may depend at least on one or more of the following: channel busy rate, sensing of PSFCH resources, data QoS characteristics, or number of group members and/or SFCI payload size.

If the HARQ-ACK/NACK scheme is used, the channel busy ratio may be used to select between different PSFCH formats (e.g., PSFCH format 0 and format 1). One or more of the following may be applied. PSFCH format 0 may be selected for high channel busy ratios (e.g., because it may include 1 or 2 symbols). For low channel busy ratios, PSFCH format 1 may be selected for low channel busy ratios (e.g., because it may include 4-14 symbols).

If the HARQ-ACK/NACK scheme is used, the sensing result of the PSFCH resources may be used to select between different PSFCH formats (e.g., PSFCH format 0 and format 1). One or more of the following may be applied. If more than 4 OFDM symbols are available on the resource, format 1 may be used. If more than 4 OFDM symbols are not available on the resource, format 0 may be used.

If a HARQ-ACK/NACK scheme is used, the data QoS characteristics (e.g., reliability requirements or minimum required communication range) may be used to select between different PFSCH formats (e.g., PSFCH format 0 and format 1). One or more of the following may be applied. For data associated with high reliability and a large minimum communication range, PSFCH format 1 may be selected. Format 0 may be selected for data that is not associated with high reliability and a large minimum communication range.

If the HARQ-ACK/NACK scheme is used, the number of group members and/or the SFCI payload size may be used to select between different PSFCH formats (e.g., PSFCH format 0 and format 1). One or more of the following may be applied. If the number of Rx WTRUs is not greater than 3 and the SFCI includes 2 bits, the PSFCH format 0 may be used. If the number of Rx WTRUs is not greater than 6 and the SFCI includes 1 bit, the PSFCH format 0 may be used. If the number of Rx WTRUs is greater than 3 and the SFCI includes 2 bits, the PSFCH format 1 may be used. If the number of Rx WTRUs is greater than 6, PSFCH format 1 may be used.

CBG type transmissions may be used (e.g., may be used only) for SL unicast transmissions (e.g., rather than SL multicast transmissions).

A sensing implementation of a Tx WTRU may be provided that takes into account the PFSCH.

The sensing implementation of the Tx WTRU may consider the PFSCH if the Tx WTRU (e.g., mode 2Tx WTRU) reserves the PSFCH resources for the Rx WTRU. Fig. 4 is an exemplary illustration of consideration of PSFCH associated with a mode 2WTRU sensing implementation. One or more of the following may be applied. The WTRU may sense (e.g., may first sense) the PSCCH and PSCCH resources. The WTRU may determine whether to transmit feedback for SL transmissions. If no feedback is sent, the WTRU may report the sensing results of the PSCCH/PSCCH (e.g., to higher layers). If feedback is to be transmitted, the WTRU may determine whether the Tx WTRU is to reserve PSFCH resources. The Tx WTRU may report the sensing result of the PSCCH/PSCCH (e.g., to higher layers) if the PSFCH resources are not reserved. If the PSFCH resources are to be reserved, the Tx WTRU may obtain information on the details of the PSFCH resources, which may include, for example, the PSFCH format, the PSFCH time domain resource size, the PSFCH frequency domain resource size, the number of WTRUs sharing common resources, the timing relationship between the PSCCH/PSSCH resources and the PSFCH resources, etc. The Tx WTRU may perform sensing of the PSFCH resources, e.g., based on the PSFCH resource details. The Tx WTRU may report the sensing results, e.g., PSCCH/PSCCH and PSFCH, to higher layers.

PSFCH resource sensing may be provided. Sensing implementations of the PSFCH resource may include one or more of: determining a transmission window of the PSFCH; determining a candidate set S from S_A(e.g., based on RSRP levels of the candidate resources); if resource R_x，yAnd resource R_x，yCollision of own transmissions or other WTRU reserved PSFCH resources (e.g., mode 1 reserved resources), then S from the candidate resource set_AIn which the resource R is removed_x，y(ii) a For the resource set S_ARanking (e.g., based on their RSSI values averaged over several time slots in the past); or report resources to a higher layer.

The transmission window of the PSFCH may be determined. One or more of the following may be applied. Sensing of PSCCH/PSCCH resources may use n + T₁，n+T₂]The transmission window of (1). Sensing of PSFCH resources may use [ n + T [ + ]₃，n+T₄]A transmission window of (2), wherein T₄＞T₃＞T₁. For T₃And T₄The selection of (a) may depend on the PSCCH/PSCCH resource selected. The candidate resource may include R_x，yAnd the set of candidate resources may include S. The candidate resource size may depend on, for example, one or more of the following: a PSFCH format, a PSFCH time domain resource size, a PSFCH frequency domain resource size, etc.

A candidate set S may be determined from S_A(e.g., based on RSRP levels of the candidate resources). One or more of the following may be applied. If a candidate resource in S has an RSRP level above a threshold, the candidate resource may be saved to S_A。

If resource R_x，yAnd resource R_x，yThe collision of own transmissions or other WTRU reserved PSFCH resources (e.g., mode 1 reserved resources) may be determined from the candidate resource set S_AIn which the resource R is removed_x，y. One or more of the following may be applied. The reserved PSFCH resources may include certain reserved parameters in the PSFCH format. In an example, if PSFCH format 0 resources are shared among multiple SL sessions, the reserved initial cyclic shift may be marked for resource avoidance. The initial cyclic shift and/or OCC sequence may be part of a PSFCH resource (e.g., in a PSFCH sensing implementation).

Can be aggregated to the resource S_ARanking is performed (e.g., based on their RSSI values averaged over several time slots in the past). One or more of the following may be applied. If S is_AIs determined (e.g., at a time from the candidate resource set S)_AIn removing resource R_x，yThereafter) not more than Thres 2M_totalThen candidate set S_AMay be from S with a smaller threshold (e.g., based on RSRP levels of the candidate resources). If S is_AIs determined (e.g., at a time from the candidate resource set S)_AIn removing resource R_x，yThereafter) greater than Thres 2M_totalThen the resource set S can be assembled_ARanking is performed (e.g., based on their RSSI values averaged over several time slots in the past). Thres2 may be different from the threshold in PSCCH/PSCCH sensing implementations.

Ranked resources (e.g., top-ranked Thres 2M)_totalSuch as S_B) May be reported to higher layers for resource selection (e.g., for final resource selection).

The Rx WTRU may receive a unicast or multicast pscch.

Fig. 5 shows an exemplary diagram associated with an Rx WTRU if the Rx WTRU receives unicast or multicast SL data. One or more of the following may be applied. The WTRU may decode (e.g., may decode first) the PSCCH. Based on the SCI information (e.g., HARQ process ID, NDI field in SCI), the WTRU may determine whether to transmit a TB (e.g., TB transmitted first or not). One or more of the following may be applied. If a TB is transmitted, the WTRU may attempt to decode the TB. If the TB is not transmitted, the WTRU may determine whether it has decoded the TB in a previous transmission. The WTRU may not send feedback if the SCI field indicates that the "PSFCH disable indicator" is ON. If the SCI field(s) indicate that the "PSFCH disable indicator" is OFF and a "HARQ-NACK" scheme is to be used, the WTRU may send NACK bit(s) (e.g., if the WTRU has a PSSCH decoding error). The WTRU may not send any information (e.g., any bits) if the WTRU has successfully decoded the psch. If the SCI field(s) indicate that the "PSFCH disable indicator" is OFF and a "HARQ-ACK/NACK" scheme is to be used, the WTRU may send NACK bit(s) if the WTRU has a pscch decoding error or the WTRU may send ACK bits if the WTRU has successfully decoded the pscch.

If the TB is not transmitted, the WTRU may determine whether it has decoded the TB in a previous transmission. One or more of the following may be applied. The WTRU may determine feedback (e.g., based on the decoded SCI information) if the WTRU has decoded the TB in a previous transmission. The WTRU may not send feedback if the SCI indicates that the PSFCH is disabled or the WTRU is to transmit an ACK for the TB. If the SCI indicates that the WTRU is to transmit an ACK (e.g., for each psch transmission), the WTRU may send one or more ACK bits. If the WTRU does not decode the TB in a previous transmission, the WTRU may combine a version (e.g., soft version) of the previously saved redundancy value RV(s) for psch decoding.

For example, the psch format and time and frequency resources may be indicated in, for example, the SCI field if there are any ACK or NACK bits to send from the WTRU.

The SFCI transmission may be performed on the psch. The WTRU may report the sidelink CSI on the PSSCH. Aperiodic CSI reporting may be performed. Semi-persistent CSI reporting may be performed. Resources for the SFCI may be computed. Beta offset may be signaled. The Tx WTRU may activate SFCI piggybacking on the psch and may determine the beta-offset (beta-offset). The Tx WTRU may activate SFCI piggybacking on the psch and the Rx WTRU may determine the beta-offset. The Rx WTRU may activate SFCI piggybacking on the psch and may determine the beta-offset.

The SFCI transmission may be provided on the psch. The WTRU may report the sidelink CSI on the PSSCH. Resources for the SFCI may be computed. Beta _ offset may be signaled.

The WTRU may report the sidelink CSI on the PSSCH. The CSI report (e.g., in NRUL) may be: aperiodic on PUSCH, periodic on PUCCH, semi-persistent (SP) on PUCCH, or SP on PUSCH. A CSI reference signal (CSI-RS) may be used as a reference signal for CSI measurement. The reference signal may be extended to CSI interference measurement (CSI-IM) and CSI-RS for interference measurement. One or more of the following may be applied.

Aperiodic CSI reporting may be performed.

The side link CSI may be reported on the psch, e.g., aperiodic and semi-persistent. For aperiodic CSI reporting, the Tx WTRU may collect sidelink CSI feedback from the Rx WTRU(s). Fig. 6 shows an exemplary diagram associated with Tx WTRU scheduling aperiodic CSI reporting.

The Tx WTRU may send the psch, which may include a sidelink CSI-RS for the Rx WTRU(s) to measure. The SCI associated with the psch transmission may include one or more of the following information: a side link CSI-RS resource; or CSI report type, timing and/or content.

The SCI associated with the psch transmission may include a sidelink CSI-RS resource. One or more of the following may be applied. Frequency (e.g., PRBs) and time (e.g., OFDM symbols) resources (e.g., for Rx WTRU measurement channels) may be indicated for the side link CSI-RS.

The SCI associated with the psch transmission may include CSI report type, timing, and content. One or more of the following may be applied. The CSI report type may be aperiodic and the CSI report content may include CQI, RI, PMI, LI, RSRP. The CSI reporting timing may be in the form of a number of slots (e.g., starting from a slot of the psch that activates the CSI report or starting from a slot that transmits an ACK for the psch that activates the CSI report). If the CSI reporting timing expires, the Rx WTRU may perform a sensing operation (e.g., to find a psch resource that includes side link CSI information). The CSI reporting timing may depend on, for example, channel availability. In an example, if the CSI reporting timing expires, the Rx WTRU may not find the psch resource to report CSI, and the reporting timing may be delayed.

A CSI reporting time window may be provided. The Tx WTRU may set the SCI field(s) to provide a time window for CSI reporting. The Rx WTRU may perform pscch resource selection within the time window.

The CSI reporting timing may depend on the number of CSI-RS resources. One or more of the following may be applied.

The Tx WTRU may set the SCI field(s) to provide CSI reporting timing (e.g., in terms of the number of pscch transmissions including CSI-RS resources). In an example, the Rx WTRU may report the side link CSI after receiving X psch transmissions with CSI-RS resources.

The CSI reporting timing may be based on a counter (e.g., a number that is decremented based on a remaining number of pschs (e.g., with CSI-RS resources) transmissions prior to CSI reporting). For example: in an initial pscch transmission with CSI-RS resources, the counter may include X; in a second PSSCH transmission with CSI-RS resources, the counter may include X-1; in a third PSSCH transmission with CSI-RS resources, the counter may include X-2, and so on. In an example, if the counter reaches 0, the Rx WTRU may find the PSSCH resource to report CSI.

The CSI reporting timing may be based on a total number of psch (e.g., with CSI-RS resources) transmissions used for CSI reporting and a counter (e.g., a number that is incremented based on an existing number of psch (e.g., with CSI-RS resources) transmissions). For example: in the initial psch transmission, the total number of psch transmissions may include X, and the counter may include 1; in the second psch transmission, the total number of psch transmissions may comprise X, and the counter may comprise 2, and so on. If the counter reaches a total number X, the Rx WTRU may find the PSSCH resource to report CSI.

The CSI reporting time window and the CSI reporting time depending on the CSI-RS resource may be used jointly. In an example, a CSI report may be sent if the CSI reporting time window or the CSI reporting time depending on CSI-RS resources is triggered.

Information associated with the CSI-RS resource (e.g., CSI report timing and content, CSI report type, etc.) may be configured (e.g., between the Tx WTRU and the Rx WTRU). In an example, the MAC-CE or SCI may include a configuration ID (e.g., to trigger aperiodic CSI reporting).

A semi-persistent CSI report may be provided.

Fig. 7 shows an exemplary diagram associated with a Tx WTRU scheduling a semi-persistent CSI report. One or more of the following may be applied.

The Tx WTRU may send a pscch that includes a sidelink CSI-RS for the Rx WTRU to measure. SCI for activating CSI reporting may include one or more of the following: a side link CSI-RS resource; or CSI reporting type, periodicity and content.

The SCI for activating CSI reporting may include sidelink CSI-RS resources. One or more of the following may be applied. Frequency (e.g., PRBs) and time (e.g., OFDM symbols) resources (e.g., to measure the channel) for the side link CSI-RS may be indicated for the Rx WTRU. The CSI-RS resource may be semi-persistent or periodic.

CSIRS resource periodicity and pscch transmission window may be provided. One or more of the following may be applied. A periodicity for the CSIRS resources may be provided. Pscch transmission with periodic CSI-RS resources may not be guaranteed (e.g., due to channel congestion or other factors). A window of psch transmissions may be provided (e.g., provided around a scheduled psch transmission (e.g., with periodic or SP CSI-RS resources)). The CSI may be measured if the psch transmission is within a time window of a scheduled psch transmission (e.g., with periodic or SP CSI-RS resources). The CSI may not be measured if the pscch transmission is outside of the window of the scheduled psch.

CSI RS resources associated with SPS (e.g., or configured grant) configuration of the psch may be provided. One or more of the following may be applied. The SP or periodic CSI RS resource may be associated with an SPs (e.g., or configured grant) configuration of the psch. The SPS (e.g., or configured grant) configuration of the psch may include CSI RS. The SCI may indicate a psch configured based on SPS (e.g., or configured grant) that includes sidelink CSI-RS resources.

The SCI used to activate CSI reporting may include CSI reporting type, periodicity, and/or content. One or more of the following may be applied. The CSI report type may be semi-persistent, and the CSI report content may include CQI, RI, PMI, LI, RSRP. The CSI reporting periodicity may be in terms of a number of slots (e.g., starting from a slot of a psch that activates the CSI report or starting from a slot that transmits an ACK for the psch that activates the CSI report). If the CSI reporting timing expires, the Rx WTRU may perform sensing operations (e.g., to find PSSCH resources to include the side link CSI information).

A time window for CSI reporting may be provided. One or more of the following may be applied. A time window may be provided for CSI reporting. The Rx WTRU may perform psch resource selection (e.g., within the time window) to report its SP CSI. The Rx WTRU may not report its SP CSI if it does not find PSSCH resources within the time window.

The CSI reporting timing may depend on the CSI-RS number. One or more of the following may be applied. The Tx WRTU may set the SCI field to provide SP CSI reporting timing (e.g., in terms of the number of pscch transmissions including SP or periodic CSI-RS resources). The CSI reporting time window and the CSI reporting time depending on the CSI-RS resource may be used jointly. In an example, a CSI report may be sent if the CSI reporting time window or CSI reporting time dependent CSI-RS is triggered.

After activating the SCI for SP CSI reporting, the psch (e.g., a subsequent psch that includes CSI-RS resources) may not include certain fields in the SCI (e.g., corresponding fields in the SCI).

The activation and deactivation of the SP CSI reports may be based on SCI content. In an example, a SCI field (e.g., a new SCI field) may be used to activate or deactivate SP CSI reporting. If the SCI field of the CSI report type is set to SP, SP CSI reporting may be activated or deactivated. In an example, if the (e.g., first time) SCI field indicates that the CSI reporting type is SP, SP CSI reporting may be activated. In an example, the SP CSI reporting may be deactivated after the SCI indicates the CSI reporting type is SP for the second time.

Information associated with the CSI-RS resource (e.g., CSI reporting periodicity, CSI reporting content, CSI reporting type, etc.) may be configured (e.g., between the Tx WTRU and the Rx WTRU). In an example, the MAC-CE or SCI may include a configuration ID, which may trigger a semi-static CSI report.

May provide for computation of resources for SFCI

UCI may be sent on PUSCH (e.g., in NR). The UCI payload (e.g., including HARQ and CSI) may be RM/polarity encoded, rate matched, and mapped onto PUSCH resources. The number of coded modulation symbols for HARQ and/or CSI may be via one or more parameters (e.g., parameters)And) It may be configured in a layer (e.g., higher layer) IE (e.g., "UCI-OnPSUSCH"). One or more (e.g., up to 4 sets) of beta _ offsets may be configured, and DCI format 0_1 may indicate which set to use.

In V2X (e.g., NRV2X), SFCI may be transmitted on PSSCH. The SFCI may be encoded by RM/polar codes and the pscch data may be encoded by LDPC codes. Bits of the SFCI (e.g., rate matching bits) may be mapped to the psch resource (e.g., the front end of the psch resource). Bits for sidelink data (e.g., rate matching)Bits) may be mapped to the psch resources (e.g., to the back end of the psch resources). The HARQ bits may be placed before the SCI bits (e.g., in the SFCI). A parameter (e.g., say a single parameter, i.e.,) May be used for side link CSI (e.g., if there is only a single partial CSI for NR V2X). Parameter (e.g. beta)) Can be used for side link HARQ-ACK.

For sidelink HARQ-ACK transmission on psch with SL data, the number of resource elements per layer for HARQ-ACK transmission may include:

one or more of the following may be applied: p_ACKThe payload of the sidelink ACK may be indicated (e.g., including a CRC); p_dataMay indicate the payload of the sidelink data; or RE_PSSCHThe total resource elements of the psch may be indicated. The remaining resource elements of the psch may be used for data transmission.

For sidelink HARQ-ACK transmission on psch without SL data, the number of resource elements per layer for HARQ-ACK transmission may include:

one or more of the following may be applied. P_CSIThe payload of the side link CSI may be indicated. The remaining resource elements of the psch may be used for side link CSI transmission.

For side link CSI transmission on PSSCH, the number of resource element(s) per layer for CSI transmission may include:

one or more of the following may be applied. P_CSIThe payload (e.g., including CRC) of the sidelink CSI may be indicated. Q_ACKResource elements allocated for the sidelink HARQ-ACK may be indicated.

Signaling for beta offset may be provided.

A device (e.g., the gNB) may configure one or more (e.g., 4) sets of beta _ offsets (e.g., where each set may include beta _ offsets for side link HARQ-ACK and beta _ offsets for side link CSI). The beta _ offset for the side link HARQ-ACK may include one or more parameters, for example, depending on the HARQ-ACK feedback payload size (e.g., less than 2 bits, between 2 and 11 bits, and greater than 11 bits). The beta _ offset of the side-link CSI may include one or more parameters, for example, depending on the CSI feedback payload size (e.g., less than or equal to 11 bits, and greater than 11 bits).

One configuration (e.g., a common configuration) may be used by one or more WTRUs (e.g., all WTRUs). For example, the SIB message may include a configuration for beta _ offset. The beta _ offset configuration may be associated with a resource pool configuration. The resource pool configuration may include a set of beta _ offsets (e.g., for HARQ-ACK and CSI).

The Tx WTRU may activate SFCI piggybacking on the psch and determine beta-offset. One or more of the following may be applied. The Tx WTRU may determine to activate SFCI piggybacking on the psch and may select a set of beta-offsets. The selection result may be indicated in the SCI. In an example, the SCI may include a field indicating which set of beta _ offsets to use. This field may include 2 bits (e.g., if a total of 4 sets of beta _ offsets are configured). This field may include 3 bits (e.g., if a total of 8 sets of beta _ offsets are configured). This field may include 1 bit (e.g., if 2 sets of beta _ offsets are configured in total). The beta _ offset field may be used as an activation for SFCI feedback. The activation may indicate (e.g., by default) that SFCI feedback is piggybacked on a pscch transmission (e.g., the next pscch transmission from an Rx WTRU). The activation may indicate (e.g., by default) the timing of the psch transmission (e.g., the next xth psch transmission from an Rx WTRU).

A device (e.g., a gNB) or resource pool may configure a single set of beta _ offsets. If a single set of beta _ offsets is configured, then a field in the SCI may not be used to indicate beta _ offset (e.g., a specific field in the SCI may not be needed), and the SCI may include bits for activating SFCI feedback.

Fig. 8 shows an example flow associated with a Tx WTRU that may activate SFCI piggybacking on psch and may determine beta _ offset. One or more of the following may be applied. A device (e.g., a gNB) may configure a set of beta _ offsets (e.g., in a common RRC message, which may be associated with a resource pool configuration). The Tx WTRU may perform one or more (e.g., several) sidelink data transmissions and may send a sidelink reference signal for CSI estimation. The Tx WTRU may determine to activate CSI feedback and/or HARQ-ACK feedback. The Tx WTRU may select a set of beta _ offsets. The WTRU may indicate the beta _ offset in the SCI. The SCI may be sent, for example, with or without sidelink data. Beta _ offset in the SCI can be used (e.g., by default) as an activation of SFCI piggybacked on PSSCH. The timing of SFCI piggybacking on the psch may be indicated in the SCI or may be set (e.g., by default) to the next sidelink data transmission from the Rx WTRU. If the Rx WTRU receives a SCI with beta _ offset, the Rx WTRU may piggyback SFCI transmissions on the PSSCH (e.g., based on the indicated beta _ offset and PSSCH timing). The SCI may indicate the beta _ offset used (e.g., for psch transmissions associated with Rx WTRUs).

The Tx WTRU may activate SFCI piggybacking on the psch and the Rx WTRU may determine the beta-offset. One or more of the following may be applied.

The Tx WTRU may activate SFCI transmission (e.g., piggyback on psch). The Tx WTRU may not determine/indicate the beta _ offset. The selection of a set of beta-offsets may be made by the Rx WTRU and may be included in the SCI (e.g., as part of a data transmission from the Rx WTRU). The selection of beta-offset may depend on the data payload, data QoS, etc. The Rx WTRU may determine (e.g., flexibly determine) resources for SFCI and data transmission.

Fig. 9 shows an example flow associated with a Tx WTRU that may activate SFCI piggybacking on PSSCH and an Rx WTRU that may determine beta _ offset. A device (e.g., a gNB) may configure a set of beta _ offsets (e.g., in an RRC message, which may be associated with a resource pool configuration). The Tx WTRU may perform one or more (e.g., several) sidelink data transmissions and may send a sidelink reference signal for CSI estimation. The Tx WTRU may determine (e.g., decide) to activate CSI feedback and/or HARQ-ACK feedback. The Tx WTRU may indicate activation of CSI feedback and/or HARQ-ACK feedback (e.g., in bits in the SCI). The activation timing may be indicated in the SCI or may be set (e.g., by default) to the next sidelink data transmission from the Rx WTRU. After receiving the active SCI, the Rx WTRU may compare the payload size of the SFCI with the payload size of the sidelink data, the data QoS, etc. The Rx WTRU may determine the beta _ offset. The Rx WTRU may map the rate-matched bits to corresponding resource elements for the SFCI (e.g., based on the determined sidelink CSI and beta _ offset of the sidelink HARQ-ACK). For example, in data transmission, the Rx WTRU may indicate the beta _ offset selection result (e.g., in the SCI).

The Rx WTRU may activate SFCI piggybacking on the psch and may determine beta-offset. One or more of the following may be applied.

The Rx WTRU may activate SFCI transmission (e.g., piggyback on psch) and may determine/indicate beta _ offset. The triggering of SFCI piggybacking on the psch may depend on the SFCI payload size. In an example, SFCI piggybacking on the pscsch may be triggered if the accumulated side link CSI feedback payload size reaches a certain threshold. In an example, SFCI piggybacking on the pscsch may be triggered if the number of HARQ-ACK bits reaches a certain threshold. In an example, SFCI piggybacking on the pscsch may be triggered if the combined accumulated sidelink CSI and HARQ-ACK bit payload size reaches a certain threshold.

The selection of the set of beta _ offsets may be included in the SCI (e.g., as part of the data transmission from the Rx WTRU). The selection of beta _ offset may depend on the data payload, data QoS, etc.

Fig. 10 shows an example flow associated with an Rx WTRU activating SFCI piggybacking on PSSCH and determining beta _ offset. One or more of the following may be applied. A device (e.g., a gNB) may configure a set of beta _ offsets (e.g., in an RRC message, which may be associated with a resource pool configuration). The Tx WTRU may have performed one or more (e.g., several) sidelink data transmissions and may send a sidelink reference signal for CSI estimation. The Rx WTRU may determine to activate CSI feedback and/or HARQ-ACK feedback, for example, based on a specific threshold for SFCI payload or data QoS. The Rx WTRU may compare the payload size of the SFCI with the payload size of the sidelink data, data QoS, etc. The Rx WTRU may determine the beta _ offset. The Rx WTRU may map the rate-matched bits to corresponding resource elements for the SFCI (e.g., based on the determined sidelink CSI and beta _ offset of the sidelink HARQ-ACK). In data transmission, the Rx WTRU may indicate the beta _ offset selection result (e.g., in the SCI).

Resource allocation for mode 1WTRU retransmissions may be provided. The Tx WTRU may request transmission resources. The Rx WTRU may report the retransmission to the gNB (e.g., in sidelink multicast).

The Tx WTRU may request retransmission resources. One or more of the following may be applied.

A Tx WTRU (e.g., a mode 1WTRU) may determine to perform (e.g., may want to perform) a unicast transmission to an Rx WTRU. The Tx WTRU may send a scheduling request for the sidelink transmission resource to the device (e.g., the gNB). The Tx WTRU may send (e.g., may also send) a sidelink buffer status report to the device (e.g., the gNB). The buffer status report may include one or more of: a destination ID; logical Channel Group (LCG) ID; a buffer size corresponding to the LCG; an indication of whether the SL transmission is unicast, multicast, or broadcast; or an indication of whether the Rx WTRU needs HARQ feedback. The apparatus (e.g., the gNB) may assign sidelink resources to the Tx WTRU based on the scheduling request from the Tx WTRU. The apparatus (e.g., the gNB) may include an indication of the PSFCH resources (e.g., whether HARQ feedback is required).

The Tx WTRU may send its data to the Rx WTRU on the assigned resources (e.g., the gNB assigned resources for SL transmission). The Rx WTRU may not decode the pscch data. The Rx WTRU may follow the SCI indication, e.g., to send a NACK bit to the Tx WTRU.

If the Tx WTRU receives a NACK bit from the Rx WTRU, the Tx WTRU may determine (e.g., decide) whether to perform retransmission, depending on the data QoS. In an example, the Tx WTRU may ignore the retransmission if the retransmission may meet the data delay requirement.

The Tx WTRU may communicate with the gNB (e.g., if the Tx WTRU determines (e.g., decides) to retransmit). One or more of the following may be applied.

The Tx WTRU may send a scheduling request (e.g., another scheduling request to the gNB). The Tx WTRU may send information for retransmission (e.g., instead of sending a new Buffer Status Report (BSR)). The information may include one or more of the following: a destination ID; updated data QoS (e.g., updated data delay requirements), LCG corresponding to the updated data QoS, backward time offset for the previous side link data transmission of the same data. The destination ID may be used to indicate which sidelink session the NACK is associated with. The side link HARQ feedback timing may be flexible. In an example, NACK feedback from the Tx WTRU to the gNB may have flexible timing. The Tx WTRU may report to the gNB (e.g., the gNB that previously scheduled the resource that generated the NACK feedback). The backward time offset (e.g., or another timing related indication) may help the gNB obtain information about the resource size for retransmission.

The Tx WTRU may send NACK bits (e.g., via PUCCH) and may indicate that the NACK information is associated with a sidelink transmission (e.g., a particular sidelink transmission). In an example, a sequence (e.g., a Gold sequence and/or an OCC sequence with a particular cyclic shift) may be used to indicate a NACK for a SL transmission. In an example, the RNTI (e.g., destination ID) may be used to scramble the PUCCH (e.g., PUCCH format 2).

If the gNB receives a Scheduling Request (SR) for a sidelink retransmission, the gNB can assign appropriate resources for the sidelink retransmission. The Tx WTRU may perform a retransmission operation (e.g., after it receives the new resources). Figure 11 shows an example flow associated with sidelink retransmission for a WTRU (e.g., a mode 1 WTRU).

Rx WTRU reports to the gNB for retransmission in sidelink multicast may be provided.

A Tx WTRU (e.g., a mode 1WTRU) may perform (e.g., may want to perform) multicast transmissions to other WTRUs. The Tx WTRU may send a scheduling request for the sidelink transmission resource to the device (e.g., the gNB). The Tx WTRU may send (e.g., may also send) a sidelink buffer status report to the device (e.g., the gNB). The buffer status report may include one or more of: a destination ID; LCG ID; a buffer size corresponding to the LCG; an indication of whether the SL transmission is unicast, multicast, or broadcast; or an indication of whether the Rx WTRU needs HARQ feedback. The apparatus (e.g., the gNB) may assign sidelink resources to the Tx WTRU based on the scheduling request from the Tx WTRU.

The Tx WTRU may send its data to the Rx WTRU (e.g., on the assigned gbb resources for SL transmission). The Rx WTRU may or may not decode the psch data. According to the HARQ-NACK scheme, one or more of the following may be applied. The Rx WTRU may successfully decode the psch data and the Rx WTRU may not send any information to the gNB. The Rx WTRU may not decode the psch data and may send one or more NACK bits (e.g., via PUCCH) to the gNB along with an indication that the NACK information is for a side link transmission. In an example, a sequence (e.g., a Gold sequence or a 0CC sequence with a particular cyclic shift) may be used to indicate that a NACK is for SL transmission. In an example, the RNTI (e.g., source ID) may be used to scramble the PUCCH (e.g., PUCCH format 2).

The Rx WTRU may inform (e.g., in addition to NACK bits) the gNB: tx WTRU ID and/or a backward time offset relative to a previous side link data transmission of the same data. This backward time offset may help the gNB to obtain information about the resource size for retransmission.

If the gNB receives NACK bits from one or more Rx WTRUs, the gNB may determine (e.g., decide) whether to perform retransmission, which may depend on the data QoS requirements. In an example, if data latency requirements may be met for retransmission, the gNB may ignore the retransmission.

If the gNB determines (e.g., decides) the resource(s) to use for the sidelink retransmission, the gNB may inform the Tx WTRU of the assigned resource(s). The gNB may indicate (e.g., may also indicate) the assigned resource(s) for side link retransmission, which may be based on a destination ID, an LCG ID, or a HARQ process ID, etc.

The Tx WTRU may perform a retransmission operation (e.g., after it receives a new resource). Figure 12 shows an example associated with WTRU (e.g., mode 1WTRU) side link retransmission.

Compact DCI 5A for the gbb scheduling LTE side link may be provided. The number of subchannels may be limited.

Compact DCI may be performed (e.g., in NR URLLC or eURLLC). Compact DCI may reduce the number of DCI format 0_0 bits (e.g., from 40 bits to about 24 bits to support URLLC service).

In V2X (e.g., NRV2X), the gNB may transmit to the WTRU using the NRDCI format (e.g., to schedule LTE sidelink transmissions). In an example, DCI format 5A may be reused (e.g., in LTE V2X). The payload of DCI format 5A may be matched to DCI format 0, e.g., in terms of payload size, to reduce blind detection (e.g., in LTE).

The payload of the DCI format (e.g., which may be used for the gNB scheduling LTE V2X sidelink) may match the size of a compact DCI (e.g., in NR URLLC service). Blind detection of V2X capable NR WTRUs may be reduced. DCI format 5A (e.g., LTE DCI format 5A) may include a maximum possible payload of greater than 24 bits. DCI format 5A may be limited to a payload size of 24 bits.

One or more of the following may apply (e.g., in LTE DCI format 5A). The carrier indicator field may include 3 bits and the maximum number of subchannels may include 20. The "lowest index allocated to a subchannel for initial transmission" field may include one or more (e.g., up to 5) bits. The "frequency resource location for initial transmission and retransmission" field may include one or more (e.g., up to 8) bits. The "time gap between initial transmission and retransmission" field may include one or more (e.g., 4 bits). The "SL index" field may include one or more (e.g., 2) bits. The SL SPS configuration index may include one or more (e.g., 3) bits. The "activation/release indication" may comprise one or more (e.g., 1) bits. The payload size (e.g., the total maximum payload size without zero padding) may include 26 bits, which may be larger than the compact DCI size (e.g., the expected compact DCI size for URLLC or eURLLC).

Compact DCI format 5A may restrict the configuration of a maximum number (e.g., 20) of subchannels of a resource pool (e.g., for LTE V2X transmissions, or in the case where the gbb will schedule LTE V2X transmissions). The possible number of subchannels of the resource pool may include {1, 3, 5, 8, 10, 15, 20} (e.g., configured according to the LTE V2X resource pool). If the usage of the resource pool is limited to a maximum of 15 sub-channels, one or more of the following may apply. The "lowest index allocated to a subchannel for initial transmission" field in DCI format 5A may include 4 bits. The "frequency resource location for initial transmission and retransmission" field in DCI format 5A may include 7 bits. The DCI format 5A payload may include 24 bits. Zero padding may not be used (e.g., to match the compact DCI size in URLLC). SL-V-RNTI or SL-SPS-V-RNTI may be used to mask one or more (e.g., the last 16 bits) CRC bits, e.g., to distinguish compact DCI format 5A from compact DCI formats of other URLLC services.

The gNB may perform one or more of the following. If the resource pool (e.g., of LTE V2X) is configured with 20 subchannels, the gNB may stop scheduling transmissions of the WTRU (e.g., LTE V2X transmissions). The gNB may schedule transmissions of the WTRU (e.g., LTE V2X transmissions) if a resource pool (e.g., of LTE V2X) is configured with no more than 20 subchannels.

Thus, techniques have been described for selecting a feedback format to be used with sidelink communications. The WTRU may select either a sidelink unicast transmission or a sidelink multicast transmission to transmit data. The WTRU may select HARQ ACK/NACK feedback for feedback associated with the data transmission if the WTRU selects side link unicast to transmit data. The HARQ NACK feedback or HARQ ACK/NACK feedback may be selected for feedback based on one or more factors or conditions if the WTRU selects a sidelink multicast transmission to transmit data. The WTRU may select HARQ NACK feedback or HARQ ACK/NACK feedback for transmission of the data according to one or more of: a number of WTRUs receiving the data; a condition of a channel associated with transmitting the data; or a quality of service associated with transmitting the data. The WTRU may select the first or second PSFCH format to provide feedback related to transmitting the data based on one or more factors or conditions. The WTRU may select the first or second PSFCH format based on one or more of: the selected side link is unicast or side link multicast; selected HARQ NACK feedback or HARQ ACK/NACK feedback; or a quality of service associated with transmitting the data.

It should be understood that although illustrative implementations have been disclosed, the scope of potential implementations is not limited to those explicitly set forth. For example, although the system has been described with reference to particular standards or conditions, contemplated implementations extend beyond implementations using particular standards or conditions. Although features and elements are described herein in particular combinations, each feature or element can be used alone without the other features and elements and/or in various combinations with or without other features and elements.

It should be appreciated that the entities performing the processes described herein may be logical entities that may be implemented in the form of software (i.e., computer-executable instructions) stored in and executed on a memory of a mobile device, network node, or computer system. That is, the operation(s) may be implemented in the form of software (i.e., computer-executable instructions) stored in a memory of a mobile device and/or a network node, such as a node or computer system, which when executed by a processor of the node performs the discussed process. It should also be understood that any of the transmitting and receiving processes shown in the figures may be performed by the communication circuitry of the node under the control of the processor of the node and the computer-executable instructions (e.g., software) that it executes.

The various techniques described herein may be implemented in connection with hardware or software or, where appropriate, with a combination of both. Thus, implementations of the subject matter described herein, or certain aspects or portions thereof, may take the form of program code (i.e., instructions) embodied in tangible media, such as flash drives, CD-ROMs, hard drives, or any other machine-readable storage medium, wherein, when the program code is loaded into and executed by a machine, such as a computer, the machine becomes an apparatus for practicing the subject matter described herein. Where program code is stored on media, it may be the case that the program code in question is stored on one or more media that collectively perform the action in question, that is, the one or more media employed together contain the code for performing the action, but where more than one single medium is present, it is not required that any particular portion of code be stored on any particular medium. In the case of program code execution on programmable devices, the computing device will generally include a processor, a storage medium readable by the processor (including volatile and non-volatile memory and/or storage elements), at least one input device, and at least one output device. One or more programs that may implement or utilize the processes described in connection with the subject matter described herein, e.g., through the use of an API, reusable controls, or the like. Such programs may be implemented in a high level procedural or object oriented programming language to communicate with a computer system. However, the program(s) can be implemented in assembly or machine language, if desired. In any case, the language may be a compiled or interpreted language, and combined with hardware implementations.

Although example embodiments may refer to utilizing aspects of the subject matter described herein in the context of one or more stand-alone computing systems, the subject matter described herein is not so limited, but may be implemented in connection with any computing environment, such as a network or distributed computing environment. Further, aspects of the subject matter described herein may be implemented in or across a plurality of processing chips or devices, and storage may similarly be effected across a plurality of devices. Such devices may include personal computers, network servers, handheld devices, supercomputers, or computers integrated into other systems such as automobiles and airplanes.

In describing illustrative implementations of the subject matter of the present disclosure, as illustrated in the figures, specific terminology is employed for the sake of clarity. However, the claimed subject matter is not intended to be limited to the specific terminology so selected, and it is to be understood that each specific element includes all technical equivalents that operate in a similar manner to accomplish a similar purpose. The particulars described herein are by way of example and not by way of limitation, of the scope of the present application.

Although features and elements are described herein in particular combinations, those of ordinary skill in the art will understand that each feature or element can be used alone or in any combination with the other features and elements. Furthermore, implementations described herein may be implemented in a computer program, software, or firmware embedded in a computer-readable medium for execution by a computer or a processor. Examples of computer readable media include electronic signals (which are transmitted over a wired or wireless connection) and computer readable storage media. Examples of computer readable storage media include, but are not limited to, read-only memory (ROM), random-access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks and Digital Versatile Disks (DVDs). A processor in association with software may be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.

52页详细技术资料下载

上一篇：一种医用注射器针头装配设备

下一篇：一种信道的接收机会确定方法及通信装置

Side link feedback channel

相关技术

网友询问留言