UE-to-UE Coordinated Feedback Transmission for V2X Sidelink Communications with Collision Avoidance

Abstract

Apparatus and systems for New Radio (NR) Vehicle-to-Everything (V2X) sidelink communications are described. UE procedures for standalone and non-standalone UE-to-UE coordinated feedback and content transmission, as well as resource selection using UE-to-UE coordinated feedback, are described. Content and containers for UE-to-UE coordinated feedback are provided, along with ordering of the resource selection process carrying UE-to-UE coordinated feedback, and transmission priority and conditions for UE-to-UE coordinated feedback. UE-to-UE coordinated feedback request, initial pre-processing of UE-to-UE coordinated feedback, assisting UE selection, and resource selection are presented.

Description

[Technical field]

[0001] This application claims the benefit of priority to U.S. Provisional Patent Application No. 63 / 230,016, filed August 5, 2021, and U.S. Provisional Patent Application No. 63 / 230,557, filed August 6, 2021, each of which is incorporated by reference in its entirety herein.

[0002] Embodiments relate to Next Generation (NG) wireless communications. In particular, some embodiments relate to New Radio (NR) Vehicle-to-Everything (V2X) sidelink communications. [Background technology]

[0003] The use and complexity of Next Generation (NG) or New Radio (NR) wireless systems, including 5G networks and beginning to include sixth generation (6G) networks in particular, is increasing due to both the increasing number of types of device user equipment (UE) using network resources and the amount of data and bandwidth being used by various applications, such as video streaming, running on those UEs. With the enormous increase in the number and variety of communication devices, the corresponding network environment, including routers, switches, bridges, gateways, firewalls, and load balancers, is becoming increasingly complex. As might be expected, with the complexity and emergence of any new technology, including vehicular communications, numerous problems arise. [Brief description of the drawings]

[0004] In the figures, which are not necessarily drawn to scale, like reference numbers may describe like components in different figures. Like reference numbers with different subscripts may represent different instances of like components. The figures generally illustrate various embodiments discussed herein by way of example, and not by way of limitation.

[0005] [Figure 1A] 1 illustrates a network architecture in accordance with some aspects.

[0006] [Figure 1B] 1 illustrates a non-roaming 5G system architecture in accordance with some aspects.

[0007] [Figure 1C] 1 illustrates a non-roaming 5G system architecture in accordance with some aspects.

[0008] [Diagram 2] 1 illustrates a block diagram of a communication device according to some embodiments.

[0009] [Figure 3A] 1 illustrates standalone UE-to-UE coordinated feedback according to some embodiments.

[0010] [Figure 3B] 1 illustrates non-standalone UE-to-UE coordinated feedback according to some embodiments.

[0011] [Figure 4A] 1 illustrates ordering of a resource selection process based on priority according to some embodiments.

[0012] [Figure 4B] 1 illustrates an ordering of the resource selection process based on feedback type according to some embodiments.

[0013] [Figure 5A] 1 illustrates a resource size alignment procedure according to some embodiments.

[0014] [Figure 5B] 1 illustrates another resource size alignment procedure according to some embodiments.

[0015] [Figure 6]FIG. 1 illustrates a block diagram of an NR V2X sidelink resource allocation procedure according to some embodiments.

[0016] [Figure 7A] FIG. 1 illustrates a block diagram of a first option for an NR V2X sidelink resource allocation procedure with UE-to-UE coordinated feedback according to some embodiments.

[0017] [Figure 7B] FIG. 1 illustrates a block diagram of a second option for an NR V2X sidelink resource allocation procedure with UE-to-UE coordinated feedback according to some embodiments.

[0018] [Figure 7C] FIG. 13 illustrates a block diagram of a third option for an NR V2X sidelink resource allocation procedure with UE-to-UE coordinated feedback according to some embodiments.

[0019] [Figure 7D] FIG. 13 illustrates a block diagram of a fourth option for NR V2X sidelink resource allocation procedure with UE-to-UE coordinated feedback according to some embodiments.

[0020] [Figure 7E] FIG. 13 illustrates a block diagram of a fifth option for an NR V2X sidelink resource allocation procedure with UE-to-UE coordinated feedback according to some embodiments.

[0021] [Figure 7F] FIG. 13 illustrates a block diagram of a sixth option for an NR V2X sidelink resource allocation procedure with UE-to-UE coordinated feedback according to some embodiments.

[0022] [Figure 7G] FIG. 13 illustrates a block diagram of a seventh option of a NR V2X sidelink resource allocation procedure with UE-to-UE coordinated feedback according to some embodiments.

[0023] [Figure 8A] 1 illustrates a procedure for removing resources not using an inter-UE coordinated resource set according to some embodiments.

[0024] [Figure 8B] 1 illustrates a resource exclusion procedure using an inter-UE coordinated resource set according to some embodiments.

[0025] [Figure 8C] 1 illustrates another resource exclusion procedure using inter-UE coordinated resource set according to some embodiments.

[0026] [Figure 8D] 1 illustrates another resource exclusion procedure using inter-UE coordinated resource sets according to some embodiments. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0027] The following description and drawings sufficiently illustrate specific embodiments to enable those skilled in the art to practice the embodiments. Other embodiments may incorporate structural, logical, electrical, process, and other changes. Portions and features of some embodiments may be included in, or substituted for, portions and features of other embodiments. The claimed embodiments encompass all available equivalents of those claims.

[0028] 1A illustrates a network architecture in accordance with some aspects. Network 140A includes 3GPP LTE / 4G and NG network functions that may be extended to 6G and later generation functions. Accordingly, although 5G is mentioned, it should be understood that this extends to 6G (and beyond) structures, systems and functions wherever possible. Network functions may be implemented as separate network elements on dedicated hardware, as software instances running on dedicated hardware, and / or as virtualized functions instantiated on a suitable platform, such as dedicated hardware or a cloud infrastructure.

[0029] Network 140A is shown to include user equipment (UE) 101 and UE 102. UE 101 and 102 are shown as smartphones (e.g., handheld touchscreen mobile computing devices capable of connecting to one or more cellular networks), but may include any mobile or non-mobile computing devices, such as portable (laptop) or desktop computers, wireless handsets, drones, or any other computing device that includes a wired and / or wireless communication interface. UE 101 and 102 may be collectively referred to herein as UE 101, which may be used to perform one or more of the techniques disclosed herein.

[0030] Any of the wireless links described herein (e.g., used in network 140A or any other illustrated network) may operate according to any exemplary wireless communication technology and / or standard. Any spectrum management scheme may be used, including, for example, dedicated licensed spectrum, unlicensed spectrum, (licensed) shared spectrum (such as Licensed Shared Access (LSA) at 2.3-2.4 GHz, 3.4-3.6 GHz, 3.6-3.8 GHz and other frequencies, and Spectrum Access System (SAS) at 3.55-3.7 GHz and other frequencies). Different single carrier or orthogonal frequency domain multiplexing (OFDM) modes (CP-OFDM, SC-FDMA, SC-OFDM, Filter Bank Based Multicarrier (FBMC), OFDMA, etc.), particularly 3GPP® NR, may be used by assigning OFDM carrier data bit vectors to corresponding symbol resources.

[0031] In some aspects, any of the UEs 101 and 102 may include an Internet of Things (IoT) UE or a Cellular IoT (CIoT) UE that may include a network access layer designed for low-power IoT applications utilizing short-lived UE connections. In some aspects, any of the UEs 101 and 102 may include a Narrowband (NB) IoT UE (e.g., enhanced NB-IoT (eNB-IoT) UE and additional enhanced (FeNB-IoT) UE, etc.). The IoT UE may utilize technologies such as Public Land Mobile Network (PLMN), Proximity Based Services (ProSe) or Device-to-Device (D2D) communications, sensor networks, or Machine-to-Machine (M2M) or Machine-Type Communications (MTC) to exchange data with an MTC server or device over the IoT network. The M2M or MTC exchange of data may be a machine-initiated exchange of data. The IoT network includes interconnecting IoT UEs that may include uniquely identifiable embedded computing devices (within the Internet infrastructure) with short-lived connections. The IoT UE may perform background applications (e.g., keep-alive messages, status updates, etc.) to facilitate connectivity to the IoT network. In some aspects, either of the UEs 101 and 102 may include an enhanced MTC (eMTC) UE or a further enhanced MTC (FeMTC) UE.

[0032] The UEs 101 and 102 may be configured to be connected, e.g., communicatively coupled, to a radio access network (RAN) 110. The RAN 110 may be, e.g., an Evolved Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access Network (E-UTRAN), a NextGen RAN (NG RAN), or some other type of RAN. The RAN 110 may include one or more gNBs, one or more of which may be implemented by multiple units. Note that although a gNB may be referred to herein, the same aspects may apply to other generation NodeBs, e.g., a 6th generation NodeB, and thus may be alternatively referred to as a radio access network node (RAN node).

[0033] Each of the gNBs may implement protocol entities in the 3GPP protocol stack, where the layers are considered to be layered from lowest to highest, in that order: physical layer (PHY), medium access control (MAC), radio link control (RLC), packet data convergence control (PDCP), and radio resource control (RRC) / service data adaptation protocol (SDAP) (for control plane / user plane). The protocol layers in each gNB may be distributed to different units, namely, a central unit (CU), at least one distributed unit (DU), and a remote radio head (RRH). The CU may provide functions such as user data forwarding control, effect mobility control, radio access network sharing, positioning, and session management, except for those functions exclusively assigned to the DU.

[0034] The higher protocol layers (PDCP and RRC for the control plane / PDCP and SDAP for the user plane) may be implemented in the CU, and the RLC and MAC layers may be implemented in the DU. The PHY layer may be split, with the higher PHY layers also implemented in the DU, while the lower PHY layers are implemented in the RRH. The CU, DU and RRH may be implemented by different manufacturers, but may still be connected by appropriate interfaces between them. A CU may be connected by multiple DUs.

[0035] Interfaces within the gNB include E1 and fronthaul (F)F1 interfaces. The E1 interface may be between the CU control plane (gNB-CU-CP) and the CU user plane (gNB-CU-UP) and therefore may support the exchange of signaling information between the control plane and the user plane via E1AP services. The E1 interface may separate the radio network layer and the transport network layer and may enable the exchange of UE-related and non-UE-related information. The E1AP services may be non-UE-related services for the entire E1 interface instance between the gNB-CU-CP and the gNB-CU-UP with non-UE-related signaling connections for a single UE and UE-related services, which are associated with the UE-related signaling connections maintained for the UE.

[0036] The F1 interface may be located between the CU and the DU. The CU may control the operation of the DU over the F1 interface. Since signaling in the gNB is divided into control plane and user plane signaling, the F1 interface may be divided into an F1-C interface for control plane signaling between the gNB-DU and the gNB-CU-CP, and an F1-U interface for user plane signaling between the gNB-DU and the gNB-CU-UP, which support the separation of the control plane and the user plane. The F1 interface may separate the radio network and the transport network layers and may enable the exchange of UE-related and non-UE-related information. In addition, the F2 interface may be between the lower and upper parts of the NR PHY layer. The F2 interface may also be separated into F2-C and F2-U interfaces based on the control plane and user plane functions.

[0037] UEs 101 and 102 utilize connections 103 and 104, respectively, each of which includes a physical communication interface or layer (described in further detail below), which in this example are illustrated as air interfaces enabling communicative coupling and may correspond to cellular communication protocols such as Global System for Mobile Communications (GSM®) protocols, Code Division Multiple Access (CDMA) network protocols, Push-to-Talk (PTT) protocols, PTT over Cellular (POC) protocols, Universal Mobile Telecommunications (UMTS) protocols, 3GPP® Long Term Evolution (LTE) protocols, 5G protocols, 6G protocols, and the like.

[0038] In an aspect, the UEs 101 and 102 may further directly exchange communication data via the ProSe interface 105. The ProSe interface 105 may alternatively be referred to as a sidelink (SL) interface that includes one or more logical channels, including, but not limited to, a physical sidelink control channel (PSCCH), a physical sidelink shared channel (PSSCH), a physical sidelink discovery channel (PSDCH), a physical sidelink broadcast channel (PSBCH), and a physical sidelink feedback channel (PSFCH).

[0039] The UE 102 is shown as configured to access an access point (AP) 106 via a connection 107. The connection 107 may include a local wireless connection, such as a connection conforming to any IEEE 802.11 protocol, according to which the AP 106 may include a Wireless Fidelity (WiFi) router. In this example, the AP 106 is shown as connected to the Internet without being connected to a core network of a wireless system (described in more detail below).

[0040] The RAN 110 may include one or more access nodes that enable the connections 103 and 104. These access nodes (AN) may be referred to as base stations (BS), NodeBs, evolved NodeBs (eNBs), next generation NodeBs (gNBs), RAN nodes, etc., and may include terrestrial stations (e.g., terrestrial access points) or satellite stations that provide coverage within a geographic area (e.g., a cell). In some aspects, the communication nodes 111 and 112 may be transmit / receive points (TRPs). When the communication nodes 111 and 112 are NodeBs (e.g., eNBs or gNBs), the one or more TRPs may function within the communication cell of the NodeB. The RAN 110 may include one or more RAN nodes for providing a macro cell, e.g., a macro RAN node 111, and one or more RAN nodes for providing a femto cell or a pico cell (e.g., a cell having a smaller coverage area, a smaller user capacity, or a higher bandwidth compared to a macro cell), e.g., a low power (LP) RAN node 112.

[0041] Any of the RAN nodes 111 and 112 may terminate air interface protocols and may be the first point of contact to the UEs 101 and 102. In some aspects, any of the RAN nodes 111 and 112 may perform various logical functions for the RAN 110, including, but not limited to, radio bearer management, uplink and downlink dynamic radio resource management and data packet scheduling, and radio network controller (RNC) functions such as mobility management. In one example, any of the nodes 111 and / or 112 may be a gNB, eNB, or another type of RAN node.

[0042] The RAN 110 is shown as communicatively coupled to a core network (CN) 120 via an S1 interface 113. In an aspect, the CN 120 may be an Evolved Packet Core (EPC) network, a NextGen Packet Core (NPC) network, or some other type of CN (e.g., as shown with reference to Figures 1B-1C). In this aspect, the S1 interface 113 is divided into two parts: an S1-U interface 114 that carries traffic data between the RAN nodes 111 and 112 and a Serving Gateway (S-GW) 122, and an S1-Mobility Management Entity (MME) interface 115 that is a signaling interface between the RAN nodes 111 and 112 and the MME 121.

[0043] In this aspect, the CN 120 includes an MME 121, an S-GW 122, a Packet Data Network (PDN) Gateway (P-GW) 123, and a Home Subscriber Server (HSS) 124. The MME 121 may be similar in function to the control plane of a legacy Serving General Packet Radio Service (GPRS) Support Node (SGSN). The MME 121 may manage mobility aspects during access such as gateway selection and tracking area list management. The HSS 124 may include a database of network users including subscription related information to support the handling of communication sessions of network entities. The CN 120 may include one or several HSSs 124 depending on the number of mobile subscribers, equipment capacity, organization of the network, etc. For example, the HSS 124 may provide support for routing / roaming, authentication, authorization, naming / addressing resolution, location dependency, etc.

[0044] The S-GW 122 may terminate the S1 interface 113 towards the RAN 110 and route data packets between the RAN 110 and the CN 120. In addition, the S-GW 122 may be a local mobility anchor point for inter-RAN node handovers and may also provide an anchor for inter-3GPP mobility. Other roles of the S-GW 122 may include lawful interception, charging, and some policy enforcement.

[0045] The P-GW 123 may terminate the SGi interface towards the PDN. The P-GW 123 may route data packets between the CN 120 and external networks, such as a network including an application server 184 (alternatively referred to as an application function (AF)) via an Internet Protocol (IP) interface 125. The P-GW 123 may also communicate data to other external networks 131A, which may include the Internet, an IP Multimedia Subsystem (IPS) network, and other networks. In general, the application server 184 may be an element providing applications (e.g., UMTS Packet Service (PS) domain, LTE PS data services, etc.) using IP bearer resources with the core network. In this aspect, the P-GW 123 is shown as communicatively coupled to the application server 184 via the IP interface 125. The application server 184 may also be configured to support one or more communication services (e.g., Voice over Internet Protocol (VoIP) sessions, PTT sessions, group communication sessions, social networking services, etc.) of the UEs 101 and 102 via the CN 120.

[0046] The P-GW 123 may further be a policy enforcement and charging data collection node. The Policy and Charging Rules Function (PCRF) 126 is the policy and charging control element of the CN 120. In a non-roaming scenario, in some aspects, there may be a single PCRF in a Home Public Land Mobile Network (HPLMN) associated with the UE's Internet Protocol Connectivity Access Network (IP-CAN) session. In a roaming scenario with local breakout of traffic, there may be two PCRFs associated with the UE's IP-CAN session, namely, a Home PCRF (H-PCRF) in the HPLMN and a Visited PCRF (V-PCRF) in a Visited Public Land Mobile Network (VPLMN). The PCRF 126 may be communicatively coupled to the application server 184 via the P-GW 123.

[0047] In some aspects, the communication network 140A may be an IoT network or a 5G or 6G network including a 5G New Radio network that employs communication in licensed (5G NR) and unlicensed (5G NR-U) spectrum. One of the current enablers of IoT is Narrowband IoT (NB-IoT). Operation in the unlicensed spectrum may include Dual Connectivity (DC) operation in the unlicensed spectrum and standalone LTE systems, according to which LTE-based technologies operate exclusively in the unlicensed spectrum without the use of an "anchor" in the licensed spectrum, called MuLTEFire. Additional enhanced operation of LTE systems in licensed as well as unlicensed spectrum is expected in future releases and 5G systems. Such enhanced operation may include techniques for sidelink resource allocation and UE processing behavior for NR sidelink V2X communications.

[0048] The NG system architecture (or 6G system architecture) may include a RAN 110 and a core network (CN) 120. The NG-RAN 110 may include multiple nodes, such as a gNB and an NG-eNB. The CN 120 (e.g., a 5G Core Network (5GC)) may include an Access and Mobility Function (AMF) and / or a User Plane Function (UPF). The AMF and UPF may be communicatively coupled to the gNB and the NG-eNB via an NG interface. More specifically, in some aspects, the gNB and the NG-eNB may be connected to the AMF by an NG-C interface and to the UPF by an NG-U interface. The gNB and the NG-eNB may be coupled to each other via an Xn interface.

[0049] In some aspects, the NG system architecture may use reference points between various nodes. In some aspects, each of the gNB and the NG-eNB may be implemented as a base station, a mobile edge server, a small cell, a home eNB, and so on. In some aspects, the gNB may be a master node (MN) and the NG-eNB may be a secondary node (SN) in the 5G architecture.

[0050] FIG. 1B illustrates a non-roaming 5G system architecture according to some aspects. In particular, FIG. 1B illustrates a 5G system architecture 140B in a reference point representation, which may be extended to a 6G system architecture. More specifically, a UE 102 may communicate with a RAN 110 and one or more other CN network entities. The 5G system architecture 140B includes a number of network functions (NFs), such as an AMF 132, a session management function (SMF) 136, a policy control function (PCF) 148, an application function (AF) 150, a UPF 134, a network slice selection function (NSSF) 142, an authentication server function (AUSF) 144, and a unified data management (UDM) / home subscriber server (HSS) 146.

[0051] The UPF 134 may provide a connection to a data network (DN) 152, which may include, for example, operator services, Internet access, or third-party services. The AMF 132 may be used to manage access control and mobility, and may also include a network slice selection function. The AMF 132 may provide UE-based authentication, authorization, mobility management, etc., and may be independent of the access technology. The SMF 136 may be configured to set up and manage various sessions according to network policies. Thus, the SMF 136 may be responsible for session management and assignment of IP addresses to the UE. The SMF 136 may also select and control the UPF 134 for data forwarding. The SMF 136 may be associated with a single session of the UE 101 or multiple sessions of the UE 101. That is, the UE 101 may have multiple 5G sessions. A different SMF may be assigned to each session. The use of different SMFs may allow each session to be managed separately. As a result, the functionality of each session may be independent of each other.

[0052] The UPF 134 can be deployed in one or more configurations according to the desired service type and can be connected with a data network. The PCF 148 can be configured to provide a policy framework with network slicing, mobility management, and roaming (similar to a PCRF in a 4G communication system). The UDM can be configured to store subscriber profiles and data (similar to a HSS in a 4G communication system).

[0053] The AF 150 may provide information on packet flows to the PCF 148, which is responsible for policy control to support the desired QoS. The PCF 148 may set mobility and session management policies for the UE 101. To this end, the PCF 148 may use the packet flow information to determine appropriate policies for appropriate operation of the AMF 132 and the SMF 136. The AUSF 144 may store data for UE authentication.

[0054] In some aspects, the 5G system architecture 140B includes multiple IP Multimedia Core Network subsystem entities, such as an IP Multimedia Subsystem (IMS) 168B, as well as a Call Session Control Function (CSCF). More specifically, the IMS 168B includes a CSCF, which can operate as a Proxy CSCF (P-CSCF) 162BE, a Serving CSCF (S-CSCF) 164B, an Emergency CSCF (E-CSCF) (not shown in FIG. 1B), or an Interrogating CSCF (I-CSCF) 166B. The P-CSCF 162B can be configured to be the first point of contact for the UE 102 in the IM Subsystem (IMS) 168B. The S-CSCF 164B can be configured to handle the session state in the network, and the E-CSCF can be configured to handle certain aspects of the emergency session, such as routing the emergency request to the correct emergency center or PSAP. The I-CSCF 166B can be configured to act as a contact point within the operator's network for all IMS connections destined for that network operator's subscribers or roaming subscribers currently located within the network operator's service area. In some aspects, the CSCF 166B can be connected to another IP multimedia network 170B, e.g., an IMS operated by a different network operator.

[0055] In some aspects, the UDM / HSS 146 may even be coupled to an application server (AS) 160B, which may include a telephony application server (TAS) or another application server. The AS 160B may be coupled to the IMS 168B via the S-CSCF 164B or the I-CSCF 166B.

[0056] The reference point representation indicates that interactions may exist between corresponding NF services. For example, FIG. 1B shows the following reference points N1 (between UE 102 and AMF 132), N2 (between RAN 110 and AMF 132), N3 (between RAN 110 and UPF 134), N4 (between SMF 136 and UPF 134), N5 (between PCF 148 and AF 150, not shown), N6 (between UPF 134 and DN 152), N7 (between SMF 136 and PCF 148, not shown), N8 (between UDM 146 and AMF 132, not shown), N9 (between two UPFs 134, not shown), N10 (between UDM 146 and SMF 136, not shown). 1B shows N11 (between AMF 132 and SMF 136, not shown), N12 (between AUSF 144 and AMF 132, not shown), N13 (between AUSF 144 and UDM 146, not shown), N14 (between two AMFs 132, not shown), N15 (between PCF 148 and AMF 132 in case of a non-roaming scenario, or between PCF 148, visited network and AMF 132 in case of a roaming scenario, not shown), N16 (between two SMFs, not shown), and N22 (between AMF 132 and NSSF 142, not shown). Other reference point representations not shown in FIG. 1B may also be used.

[0057] 1C shows a 5G system architecture 140C and a service-based representation. In addition to the network entities shown in FIG. 1B, the system architecture 140C can also include a network publication function (NEF) 154 and a network repository function (NRF) 156. In some aspects, the 5G system architecture can be service-based, and the interactions between network functions can be represented by corresponding point-to-point reference points Ni or service-based interfaces.

[0058] In some aspects, as shown in Figure 1C, a service-based representation can be used to represent network functions in a control plane that allow other authorized network functions to access those services. In this regard, the 5G system architecture 140C can include the following service-based interfaces: Namf 158H (service-based interface indicated by AMF 132), Nsmf 158I (service-based interface indicated by SMF 136), Nnef 158B (service-based interface indicated by NEF 154), Npcf 158D (service-based interface indicated by PCF 148), Nudm 158E (service-based interface indicated by UDM 146), Naf 158F (service-based interface indicated by AF 150), Nnrf 158C (service-based interface indicated by NRF 156), Nnssf 158A (service-based interface indicated by NSSF 142), and Nausf 158G (service-based interface indicated by AUSF 144). Other service-based interfaces not shown in FIG. 1C (eg, Nudr, N5g-eir, and Nudsf) can also be used.

[0059] The NR-V2X architecture may support reliable, low-latency sidelink communications with a variety of traffic patterns, including periodic and aperiodic communications with random packet arrival times and sizes. The techniques disclosed herein can be used to support high reliability in distributed communication systems with dynamic topologies, including sidelink NR V2X communication systems.

[0060] FIG. 2 illustrates a block diagram of a communication device according to some embodiments. The communication device 200 may be a dedicated network appliance such as a dedicated computer, a personal or laptop computer (PC), a UE such as a tablet PC or smartphone, an eNB, software running on a server to configure the server to operate as a network device, a virtual device, or any machine capable of executing (sequentially or otherwise) instructions that specify actions to be taken by the machine. For example, the communication device 200 may be implemented as one or more of the devices illustrated in FIG. 1A through FIG. 1C. It is noted that the communications described herein may be encoded prior to transmission by a transmitting entity (e.g., UE, gNB) for reception by a receiving entity (e.g., gNB, UE) and decoded after reception by the receiving entity.

[0061] As described herein, examples may include or operate on logic or multiple components, modules, or mechanisms. Modules and components are tangible entities (e.g., hardware) capable of performing certain operations and may be configured or arranged in a certain manner. In one example, a circuit may be configured in a certain manner (e.g., internally or with respect to external entities such as other circuits) as a module. In one example, all or a portion of one or more computer systems (e.g., standalone, client, or server computer systems) or one or more hardware processors may be configured by firmware or software (e.g., instructions, application parts, or applications) as modules that operate to perform certain operations. In one example, the software may reside on a machine-readable medium. In one example, the software, when executed by the underlying hardware of a module, causes the hardware to perform certain operations.

[0062] Thus, the terms "module" (and "component") are understood to encompass tangible entities that are physically constructed entities and that are specifically configured (e.g., hardwired) or temporarily (e.g., transiently) configured (e.g., programmed) to operate in a particular manner or to perform some or all of the operations described herein. When considering examples where modules are temporarily configured, each of the modules need not be instantiated at any one time. For example, if the modules have a general-purpose hardware processor that is configured using software, the general-purpose hardware processor may be configured as different modules at different times. Thus, the software may configure the hardware processor, for example, to configure a particular module at one time and another module at a different time.

[0063] The communication device 200 may include a hardware processor (or equivalent processing circuitry) 202 (e.g., a central processing unit (CPU), a GPU, a hardware processor core, or any combination thereof), a main memory 204, and a static memory 206, some or all of which may be in communication with each other via an interlink (e.g., a bus) 208. The main memory 204 may include any or all of removable and non-removable storage, volatile memory, or non-volatile memory. The communication device 200 may further include a display unit 210, such as a video display, an alphanumeric input device 212 (e.g., a keyboard), and a user interface (UI) navigation device 214 (e.g., a mouse). In one example, the display unit 210, the input device 212, and the UI navigation device 214 may be touch screen displays. The communication device 200 may additionally include a storage device (e.g., a drive unit) 216, a signal generating device 218 (e.g., a speaker), a network interface device 220, and one or more sensors, such as a global positioning system (GPS) sensor, a compass, an accelerometer, or other sensor. The communication device 200 may further include an output controller, such as a serial (e.g., Universal Serial Bus (USB), parallel, or other wired or wireless (e.g., infrared (IR), near field communication (NFC), etc.) connection, to communicate with or control one or more peripheral devices (e.g., a printer, a card reader, etc.).

[0064] Storage device 216 may include a non-transitory machine-readable medium 222 (hereinafter simply referred to as machine-readable medium) having stored thereon one or more data structures or sets of instructions 224 (e.g., software) embodied or utilized by any one or more of the techniques or functions described herein. Instructions 224 may also reside, completely or at least partially, within main memory 204, static memory 206, and / or within hardware processor 202 during their execution by communications device 200. While machine-readable medium 222 is depicted as a single medium, the term "machine-readable medium" may include a single medium or multiple media (e.g., a centralized or distributed database and / or associated caches and servers) configured to store one or more instructions 224.

[0065] The term "machine-readable medium" may include any medium capable of storing, encoding, or carrying instructions for execution by communication device 200 and causing communication device 200 to perform any one or more of the techniques of this disclosure, or any medium capable of storing, encoding, or carrying data structures used by or associated with such instructions. Non-limiting examples of machine-readable media may include solid-state memories, and optical and magnetic media. Specific examples of machine-readable media may include non-volatile memory, such as semiconductor memory devices (e.g., electrically programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM)) and flash memory devices, magnetic disks, such as internal hard disks and removable disks, optical and magnetic disks, random access memory (RAM), and CD-ROM and DVD-ROM disks.

[0066] The instructions 224 may further be transmitted or received over a communications network using a transmission medium 226 via a network interface device 220 utilizing any one of a number of wireless local area network (WLAN) transport protocols (e.g., Frame Relay, Internet Protocol (IP), Transmission Control Protocol (TCP), User Datagram Protocol (UDP), Hypertext Transfer Protocol (HTTP), etc.). Exemplary communications networks may include a local area network (LAN), a wide area network (WAN), a packet data network (e.g., the Internet), a mobile telephone network (e.g., a cellular network), a plain old telephone (POTS) network, and a wireless data network. Communications over the network may include one or more different protocols, such as the Institute of Electrical and Electronics Engineers (IEEE) 802.11 family of standards known as Wi-Fi, the IEEE 802.16 family of standards known as WiMax, the IEEE 802.15.4 family of standards, the Long Term Evolution (LTE) family of standards, the Universal Mobile Telecommunications System (UMTS) family of standards, peer-to-peer (P2P) networks, Next Generation (NG) / Fifth Generation (5G) standards, among others. In one example, the network interface device 220 may include one or more physical jacks (e.g., Ethernet, coaxial, or phone jack) or one or more antennas to connect to the transmission medium 226.

[0067] It is noted that the term "circuitry" as used herein refers to or includes a portion of hardware components configured to provide a described functionality, such as electronic circuits, logic circuits, processors (shared, dedicated, or groups), and / or memories (shared, dedicated, or groups), application specific integrated circuits (ASICs), field programmable devices (FPDs) (e.g., field programmable gate arrays (FPGAs), programmable logic devices (PLDs), complex PLDs (CPLDs), high capacity PLDs (HCPLDs), structured ASICs, or programmable SoCs), digital signal processors (DSPs), etc. In some embodiments, a circuitry may execute one or more software or firmware programs to provide at least some of the described functionality. The term "circuitry" may also refer to a combination of one or more hardware elements (or a combination of circuits used in an electrical or electronic system) with program code used to perform the functions of that program code. In these embodiments, the combination of hardware elements and program code may be referred to as a particular type of circuitry.

[0068] The term "processor circuitry" or "processor" as used herein therefore refers to, is a part of, or includes circuitry capable of sequentially and automatically performing a series of arithmetic or logical operations, or recording, storing, and / or transmitting digital data. The term "processor circuitry" or "processor" may refer to one or more application processors, one or more baseband processors, physical central processing units (CPUs), single or multi-core processors, and / or any other device capable of executing or otherwise operating computer-executable instructions, such as program code, software modules, and / or functional processes.

[0069] Any of the wireless links described herein may operate according to any one or more of the following wireless communication technologies and / or standards, including, but not limited to, Global System for Mobile Communications (GSM) wireless communication technology, General Packet Radio Service (GPRS) wireless communication technology, Enhanced Data Rates for GSM Evolution (EDGE) wireless communication technology, and / or Third Generation Partnership Project (3GPP) wireless communication technologies, such as Universal Mobile Telecommunications System (UMTS), Freedom of Multimedia Access (FOMA), 3GPP Long Term Evolution (LTE), 3GPP Long Term Evolution Advanced (LTE Advanced), Code Division Multiple Access 2000 (CDMA2000), Cellular Digital Packet Data (CDMA2000), and / or 3GPP LTE (3GPP LTE-Advanced). Data (CDPD), Mobitex, Third Generation (3G), Circuit Switched Data (CSD), High Speed ​​Circuit Switched Data (HSCSD), Universal Mobile Telecommunications System (3rd Generation) (UMTS (3G)), Wideband Code Division Multiple Access (W-CDMA (UMTS)), High Speed ​​Packet Access (HSPA), High Speed ​​Downlink Packet Access (HSDPA), High Speed ​​Uplink Packet Access (HSUPA), High Speed ​​Packet Access Plus (HSPA+), Universal Mobile Telecommunications System Time Division Duplex (UMTS-TDD), Time Division Code Division Multiple Access (TD-CDMA), Time Division Synchronous Code Division Multiple Access (TD-SCDMA), 3rd Generation Partnership Project Release 8 (Pre-4th Generation) (3GPP Rel.8 (Pre-4G)), 3GPP Rel.9 (3rd Generation Partnership Project Release 9), 3GPP Rel.10 (3rd Generation Partnership Project Release 10), 3GPP Rel.11 (3rd Generation Partnership Project Release 11), 3GPP Rel.12 (3rd Generation Partnership Project Release 12), 3GPP Rel.13 (3rd Generation Partnership Project Release 13), 3GPP Rel.14 (3rd Generation Partnership Project Release 14), 3GPP Rel.15 (3rd Generation Partnership Project Release 15), 3GPP Rel.16 (3rd Generation Partnership Project Release 16), 3GPP Rel.17 (3rd Generation Partnership Project Release 17) and subsequent releases (Rel.18, Rel.19, etc.), 3GPP5G, 5G, 5G New Wireless (5G NR), 3GPP5G New Wireless, 3GPP LTE Extra, LTE Advanced Pro, LTE Licensed Assisted Access (LAA), MuLTEFire, UMTS Terrestrial Radio Access (UTRA), Evolved UMTS Terrestrial Radio Access (E-UTRA), Long Term Evolution Advanced (4th Generation) (LTE Advanced (4G)), cdmaOne (2G), Code Division Multiple Access 2000 (3rd Generation) (CDMA2000 (3G)), Evolution Data Optimized or Evolution Data Only (EV-DO), Advanced Mobile Phone System (1st Generation) (AMPS (1G)), Total Access Communications System / Enhanced Total Access Communications System (TACS / ETACS), Digital AMPS (2nd Generation) (D-AMPS (2G)), Push-To-Talk (PTT), Mobile Telephone System (MTS), Improved Mobile Telephone System (IMTS), Advanced Mobile Telephone System (AMTS), OLT (Offentlig Landmobile in Norwegian) Telefoni, Public Land Mobile Telephony, MTD (an abbreviation of the Swedish Mobiltelefonisystem or Mobile telephony system D), Public Automatic Land Mobile (Autotel / PALM), ARP (Finnish Autoradiopuhelin "car radio phone"), NMT (Nordic Mobile Telephony), NTT (Nippon Telegraph and Telephone) high capacity version (Hicap), Cellular Digital Packet Data (CDPD), Mobitex, DataTAC, Integrated Digital Enhanced Network (iDEN), Personal Digital Cellular (PDC), Circuit Switched Data (CSD), Personal Handy Phone System (PHS®), Broadband Integrated Digital Enhanced Network (WiDEN), iBurst, Unlicensed Mobile Access (UMA) (also known as the 3GPP Generic Access Network or GAN standard), Zigbee®, Bluetooth®(r), Wireless Gigabit Alliance (WiGig) standard, mmWave standard in general (WiGig, IEEE 802.wireless systems operating at 10-300 GHz and higher, such as IEEE 802.11ad, IEEE 802.11ay, etc.), technologies operating in the 300 GHz and higher THz bands, Vehicle-to-Vehicle (V2V) and Vehicle-to-X (V2X) and Vehicle-to-Infrastructure (V2I) and Infrastructure-to-Vehicle (I2V) communication technologies (3GPP / LTE based or IEEE 802.11p or IEEE 802.11bd and other), Dedicated Short Range Communications (DSRC) communication systems such as 3GPP Cellular V2X, Intelligent Transport Systems and others (typically operating at 5850 MHz to 5925 MHz or higher (typically up to 5935 MHz as per the proposed changes in CEPT Report 71)), European ITS-G5 systems (i.e. IEEE European flavors of 802.11p-based DSRC, including ITS-G5A (i.e., ITS-G5 operation in the European ITS frequency bands dedicated to ITS for safety-related applications in the frequency range from 5,875 GHz to 5,905 GHz), ITS-G5B (i.e., operation in the European ITS frequency bands dedicated to ITS non-safety applications in the frequency range from 5,855 GHz to 5,875 GHz), ITS-G5C (i.e., operation of ITS applications in the frequency range from 5,470 GHz to 5,725 GHz), Japanese DSRC in the 700 MHz band (715 MHz to 725 MHz inclusive), and IEEE 802.11bd-based systems.

[0070] The aspects described herein may be used in the context of any spectrum management scheme, including dedicated licensed spectrum, unlicensed spectrum, licensed exempt spectrum, (licensed) shared spectrum (such as LSA=Licensed Shared Access in 2.3-2.4 GHz, 3.4-3.6 GHz, 3.6-3.8 GHz and further frequencies, and SAS=Spectrum Access System / CBRS=Citizen Broadband Radio System in 3.55-3.7 GHz and further frequencies).Applicable spectrum bands include IMT (International Mobile Telecommunications) spectrum, as well as national allocations (including 450-470 MHz, 902-928 MHz) (Note: allocated, for example, in the United States (FCC Part 15)), 863-868.6 MHz (Note: allocated, for example, in the European Union (ETSI EN300 220)), 915.9-929.7 MHz (Note: allocated, for example, in Japan), 917-923.5 MHz (Note: allocated, for example, in South Korea), 755-779 MHz and 779-787 MHz (Note: allocated, for example, in China), 790-960 MHz, 1710-2025 MHz, 2110-2200 MHz, 2300-2400 MHz, 2.4-2.4835 GHz (Note: ISM bands with global availability and not included in the Wi-Fi technology family (11b / g / n / ax) and Bluetooth®), 2500-2690 MHz, 698-790 MHz, 610-790 MHz, 3400-3600 MHz, 3400-3800 MHz, 3800-4200 MHz, 3.55-3.7 GHz (Note: allocated in the United States, for example, for Citizen Broadband Radio Service), 5.15-5.25 GHz and 5.25-5.35 GHz and 5.47-5.725 GHz and 5.725-5.85 GHz bands ... The following bands are currently being considered for use in the U-NII bands: 5.725-5.875 GHz (Note: allocated, for example, in the EU (ETSI EN301 893)), 5.47-5.65 GHz (Note: allocated, for example, in South Korea), 5925-7125 MHz, and 5925-6425 MHz (Note: under consideration in the US and EU, respectively). Note that next-generation Wi-Fi systems are expected to include the 6 GHz spectrum as an operating band, but as of December 2017, Wi-Fi systems are not yet permitted in this band. Regulation is expected to be completed during the 2019-2020 period.), IMT Advanced spectrum, IMT-2020 spectrum (expected to include 3600-3800 MHz, 3800-4200 MHz, 3.5 GHz bands, 700 MHz bands, and bands in the 24.25-86 GHz range, etc.), spectrum available under the FCC's "Spectrum Frontier" 5G initiative (27.5-28.35 GHz, 29.1-29.25 GHz, 31-31.3 GHz, 37-38.6 GHz, including 38.6-40 GHz, 42-42.5 GHz, 57-64 GHz, 71-76 GHz, 81-86 GHz, and 92-94 GHz, etc.), 5.9 GHz (typically 5.85-5.925 GHz) and 63-64 GHz ITS (Intelligent Transport Systems) spectrum. Systems band, bands currently allocated to WiGig, such as WiGig Band 1 (57.24-59.40 GHz), WiGig Band 2' (59.40-61.56 GHz) and WiGig Band 3 (61.56-63.72 GHz) and WiGig Band 4 (63.72-65.88 GHz), other types of spectrum / bands such as the band with 57-64 / 66 GHz (Note: this band has the near-global designation for Multi-Gigabit Wireless Systems (MGWS) / WiGig). In the United States (FCC Part 15) a total of 14 GHz spectrum has been allocated, while in the EU (ETSI EN302 567 and ETSI EN301 217-2 for fixed P2P) a total of 9 GHz spectrum has been allocated, the 70.2 GHz-71 GHz band, any band between 65.88 GHz and 71 GHz, bands such as 76-81 GHz currently allocated to automotive radar applications, and future bands including 94-300 GHz and higher. Furthermore, schemes can be used based secondarily on bands such as TV white space bands (typically below 790 MHz), with the 400 MHz and 700 MHz bands being promising candidates in particular. In addition to cellular applications, specific applications for vertical markets can be addressed, such as PMSE (Program Production and Special Events), medical, health, surgery, automotive, low latency, drones, and other applications.

[0071] The embodiments described herein may also implement hierarchical application of the scheme, for example, by introducing hierarchical prioritization of usage for different types of users (e.g., low / medium / high priority, etc.) based on prioritized access to spectrum, such as Tier 1 users having the highest priority, followed by Tier 2 users, then Tier-3 users, etc.

[0072] The aspects described herein may also be applied to different single carrier or OFDM flavors (CP-OFDM, SC-FDMA, SC-OFDM, Filter Bank Based Multi-Carrier (FBMC), OFDMA, etc.), particularly to 3GPP NR (New Radio), by allocating OFDM carrier data bit vectors to corresponding symbol resources.

[0073] 5G networks extend beyond traditional mobile broadband services to provide a variety of new services, such as the Internet of Things (IoT), industrial control, autonomous driving, and mission-critical communications, which may have requirements for ultra-low latency, ultra-high reliability, and high data capacity due to safety and performance concerns. Some of the features in this specification are defined for the network side, such as AP, eNB, NR, or gNB, as this term is typically used in the context of 3GPP's 5G and 6G communication systems. In addition, the UE may also play this role and function as an AP, eNB, or gNB; that is, some or all of the features defined for the network equipment may be implemented by the UE.

[0074] As mentioned above, NR V2X sidelink communication is a synchronous communication system with distributed resource allocation. UEs autonomously select resources for sidelink transmission based on a predefined sensing and resource selection procedure implemented by the transmitter (TX) UE. The sensing and resource selection procedure is designed to reduce potential sidelink contention (e.g., collision or half-duplex contention) in transmission or resource reservation. Considering that the sensing and resource selection procedure is performed only by the TX UE and does not consider the receiver (RX) side environment, the possibility of sidelink contention (collision) cannot be ignored. To address this issue, inter-UE cooperative feedback from the RX UE can be used to improve resource allocation decisions by the TX UE and improve the overall reliability of NR-V2X sidelink communication.

[0075] In some embodiments, two types of transmissions may be used to deliver UE-to-UE coordinated feedback to the TX UEs, which may be used to minimize co-channel and half-duplex issues of feedback delivery and keep the overhead from feedback transmission small without noticeable impact on the overall system loading.

[0076] Two high-level inter-UE cooperation solutions can be used to improve NR V2X sidelink performance: inter-UE cooperation scheme #1 (sidelink contention / collision avoidance) and inter-UE cooperation scheme #2 (sidelink contention resolution).

[0077] Inter-UE coordination scheme #1 (sidelink contention / collision avoidance) aims to avoid half-duplex and collision issues for NR V2X communications by utilizing inter-UE coordinated feedback. In this case, UEs providing inter-UE coordinated feedback report a set of preferred and / or non-preferred resources to surrounding sidelink transmitters. The sidelink transmitters then apply a TX-based sensing procedure to select / reserve sidelink resources for transmissions using the received inter-UE coordinated feedback to avoid potential sidelink communication contention.

[0078] Inter-UE cooperation scheme #2 (sidelink contention resolution) aims to resolve sidelink contentions, either already occurring contentions or potential future contentions detected based on resource reservation signaling, utilizing inter-UE cooperation feedback. It is used to inform the sidelink transmitter about the detected sidelink contention via inter-UE cooperation feedback so that the TX UE can reselect resources for transmission or continue transmission on reserved resources, either by performing additional retransmissions or by dropping the planned transmission.

[0079] Support for UE-to-UE coordination scheme #1 may include a number of aspects, including UE procedures / methods for generating UE-to-UE coordinated feedback, UE procedures / methods for determining UE-to-UE coordinated feedback cast type and target UE, UE procedures / methods for transmitting UE-to-UE coordinated feedback and its content, UE-to-UE coordinated feedback reference time and aging information, reference parameters for generating UE-to-UE coordinated feedback, UE procedures / methods for resource selection using UE-to-UE coordinated feedback, and details of UE-to-UE coordinated signaling.

[0080] UE Behavior for UE-to-UE Cooperative Feedback and Its Content Transmission

[0081] Collaborative feedback and content between standalone / non-standalone UEs

[0082] One of the open questions is whether the assisting UE (UE-A) may transmit standalone UE-to-UE coordinated feedback or only non-standalone UE-to-UE coordinated feedback (i.e., sidelink transmission with only UE-to-UE coordinated payload without other data / control signaling). In general, transmitting standalone UE-to-UE coordinated feedback may cause additional interference and half-duplex problems from a system perspective. However, such transmission may be the only option when feedback is requested by the TX UE and the assisting UE has no data for transmission. In a more general scenario, the assisting UE may transmit feedback to the TX UE along with other parallel data / traffic.

[0083] Accordingly, two options of inter-UE coordinated feedback transmission may be considered: stand-alone inter-UE coordinated feedback and non-stand-alone inter-UE coordinated feedback.

[0084] Option 1: Standalone UE-to-UE Cooperative Feedback

[0085] In this case, feedback is transmitted even if the assisting UE has no other additional data for sidelink transmission / communication. Standalone UE-to-UE coordinated feedback may be supported and generated upon request from the TX UE and may be applicable to unicast and groupcast communication (e.g., when the assisting UE is requested by the TX UE to provide UE-to-UE coordinated feedback but has no data of its own for transmission towards the target TX UE). Support for standalone transmission may not have a significant impact on the sidelink physical structure introduced in R16 / R17. The request for feedback may be carried via Sidelink Control Information (SCI) Format X (e.g., Hybrid Automatic Repeat Request (HARQ) / Channel State Information (CSI) Feedback Request) or using MAC Control Element (MAC-CE) / RRC signaling carried as a Physical Sidelink Shared Channel (PSSCH) payload.

[0086] For example, standalone feedback may be used to deliver assistance information to TX UEs performing unicast or groupcast semi-persistent transmissions. The TX UE may request UE-to-UE coordinated feedback for a specific time interval in the future (e.g., resource selection window) and provide parameters to the assisting UEs so that the feedback is generated and received just before the next resource reselection for the semi-persistent process. Figure 3A illustrates standalone UE-to-UE coordinated feedback according to some embodiments.

[0087] Option 2: Coordinated feedback between non-standalone UEs

[0088] In this case, the UE-to-UE coordinated feedback is transmitted when the supporting UE has other / additional data for sidelink transmission communication. The transmission of the non-standalone UE-to-UE coordinated feedback has no impact on the physical structure. The feedback is carried via MAC CE multiplexed with other data and may be transmitted via PSSCH. Figure 3B illustrates the non-standalone UE-to-UE coordinated feedback according to some embodiments.

[0089] From a system perspective, non-standalone UE-to-UE coordinated feedback may be a viable option since it does not intentionally increase sidelink half-duplex and co-channel collision problems. At the same time, if UE-to-UE coordinated feedback is requested by the TX UE via a unicast connection, then UE-to-UE coordinated feedback may also be provided in a standalone manner (e.g., using MAC CE signaling). It is also possible that the assisting UE is requested to provide unicast feedback but only has broadcast / groupcast or unicast information for another UE (i.e., not intended for transmission to the TX UE). In this case, the assisting UE may use broadcast transmission to provide UE-to-UE coordinated feedback multiplexed with broadcast / groupcast or unicast information for other UEs.

[0090] The content of the UE-to-UE coordinated feedback may depend on the type of communication used for the feedback transmission (referred to as the cast type) and whether the UE-to-UE coordinated feedback is a standalone or non-standalone sidelink transmission.

[0091] Content and container of UE-to-UE collaborative feedback

[0092] The following containers may be considered to carry inter-UE coordinated feedback for sidelink contention avoidance: SCI format 2 (stage 2), MAC CE, PC5 RRC signaling.

[0093] Using MAC CE may be desirable since it may offer flexibility in payload size as well as reasonable latency and multiple UE-to-UE coordinated feedback transmissions may be multiplexed with other sidelink data in a single transmission.

[0094] The following table gives an overview of potential information fields that may be provided as part of inter-UE coordinated feedback in Scheme 1. [Table 1] [Table 1]

[0095] Sequencing of resource selection process conveying inter-UE coordinated feedback

[0096] If a UE has multiple sidelink sessions with different cast types, the scheduling between the cast types can be left to the UE implementation. The ordering of resource selection can be performed according to the priority of the sidelink transmissions with associated inter-UE coordinated feedback. For transmissions of equal priority, the following resource selection ordering rules can be applied:

[0097] Example 1: Transmission with inter-UE coordinated feedback>transmission without inter-UE coordinated feedback (ie, resource selection is made first / prioritized for transmission with inter-UE coordinated feedback).

[0098] Example 2: Chia unicast with inter-UE coordinated feedback > groupcast with inter-UE coordinated feedback > broadcast with inter-UE coordinated feedback > transmission without inter-UE coordinated feedback.

[0099] Example 3: Broadcast with inter-UE coordinated feedback > Groupcast with inter-UE coordinated feedback > Unicast with inter-UE coordinated feedback > Transmission without inter-UE coordinated feedback.

[0100] 4A illustrates an ordering of the resource selection process based on priority according to some embodiments. FIG. 4B illustrates an ordering of the resource selection process based on feedback type according to some embodiments. As shown in FIG. 4B, broadcast feedback has higher priority than groupcast feedback, which has higher priority than unicast feedback, which has higher priority than transmissions without feedback.

[0101] The pre-selected / pre-reserved resources may be excluded from resource selection for a subsequent selection process that is performed in parallel (i.e., simultaneously) on the UE selected resources.

[0102] Priority of UE-to-UE Cooperative Feedback Transmission

[0103] For inter-UE coordination scheme 1 (sidelink contention avoidance), the assisting UE not only transmits inter-UE coordinated feedback but also transmits or receives user / control plane data. If multiplexing both transmissions is not possible, the UE may decide what to transmit first. To address such situations, inter-UE coordinated feedback may be associated with a sidelink transmission priority that may be used to decide which transmission should be pursued first, i.e. which transmission has higher priority. In general, the following options are considered:

[0104] Option 1: Regular sidelink (user / control plane) transmission is prioritized over UE-to-UE coordinated feedback transmission / reception (which may be pre-defined or subject to pre-configured signaling).

[0105] Option 2: Inter-UE coordinated feedback transmission / reception is prioritized over periodic sidelink transmission / reception (which may be predefined or subject to pre-configured signaling).

[0106] Option 3: The inter-UE coordinated feedback is associated with a sidelink transmission priority. The sidelink transmission priority level of the inter-UE coordinated feedback and the periodic sidelink transmission are used to decide whether the transmission / reception of the inter-UE coordinated feedback is prioritized over the periodic sidelink transmission.

[0107] Option 4: UE-to-UE coordinated feedback is multiplexed with periodic sidelink transmissions and the highest priority level of the two is associated with the multiplexed sidelink transmissions.

[0108] The priority of the UE-to-UE coordinated feedback may utilize several different modes.

[0109] Pre-configured: Here, the priority level of UE-to-UE coordinated feedback may be pre-configured by the gNB / network using RRC signaling or the application layer (e.g., for broadcasting UE-to-UE coordinated feedback).

[0110] Different cast types (broadcast / groupcast / unicast) of inter-UE coordinated feedback may be associated with different priority levels.

[0111] Determined by the supporting UE.

[0112] It is derived from the priority level of the supporting UE's sidelink transmission.

[0113] Target TX is derived from the UE's transmission priority.

[0114] It is determined by the assisting UE based on the priority level of the sidelink transmission of the target TX UE requesting inter-UE coordinated feedback (e.g., for unicast / groupcast inter-UE coordinated feedback).

[0115] Conditions for transmitting cooperative feedback between UEs

[0116] The following set of conditions may be used to enable the generation and triggering of transmission of UE-to-UE coordinated feedback.

[0117] Condition 1: UE-to-UE coordinated feedback is enabled per sidelink resource pool. In addition, the following configurations may be provided for a particular UE-to-UE coordinated feedback type: if not predefined, a configuration to be enabled for standalone or non-standalone UE-to-UE coordinated feedback of the resource pool; if not predefined, a configuration to be enabled for semi-persistent only / dynamic only or both semi-persistent and dynamic resource allocation based UE-to-UE coordinated feedback of the resource pool; and if not predefined, a configuration of enabled UE-to-UE coordinated feedback cast type / destination or format.

[0118] Condition 2: The UE receives a request from another UE (eg, a UE group member) to provide a particular type of inter-UE coordinated feedback.

[0119] Condition 3: The UE is configured by higher layers to provide inter-UE coordinated feedback and has data available for sidelink transmission (non-standalone inter-UE coordinated feedback).

[0120] Condition 4: The upper layer triggers the transmission of the UE-to-UE coordinated feedback based on a timer condition, which may be a preset amount of time since the previous trigger for the transmission of the UE-to-UE coordinated feedback.

[0121] Condition 5: Higher layers trigger UE-to-UE coordinated feedback based on a moving distance condition, which may be moving a preset distance since the previous trigger / transmission of UE-to-UE coordinated feedback.

[0122] Condition 6: The UE is provided with a configuration setting, e.g., a reference configuration for UE-to-UE coordinated feedback (i.e., sensing-based preferred / non-preferred resource sets for sidelink resource selection procedure), to generate UE-to-UE coordinated feedback. Alternatively, the UE may use a default setting.

[0123] Condition 7: Sidelink transmission of UE-to-UE coordinated feedback is configured and activated, for example, by higher layer signaling or by the UE and / or gNB.

[0124] Condition 8: The congestion control status indicates that the channel is not significantly overloaded. In this case, UE-to-UE coordinated feedback is generated based on the constant bit rate (CBR) setting (i.e., the CBR measurement is within a pre-configured range).

[0125] Condition 9: The UE has selected or reserved sidelink resources for its own potential sidelink transmission and wants to update other UEs to avoid potential sidelink contention.

[0126] Condition 10: The UE generates UE-to-UE coordinated feedback if: 1) the sidelink reference signal received power (SL-RSRP) threshold used to construct the (preferred / non-preferred) resource set is greater than / less than a pre-configured value of the SL-RSPR threshold configured to trigger UE-to-UE coordinated feedback, and / or 2) the size of the set is within a pre-configured range [X1,X2], which may be defined for the number of resources in a selected time interval.

[0127] The above sets of conditions may be applied in any possible combination to determine when a UE may generate inter-UE coordinated feedback.

[0128] UE Procedures / Methods for Resource Selection Using Inter-UE Coordinated Feedback

[0129] Each TX UE may receive inter-UE coordinated feedback from one or more UEs. In addition, the feedback may arrive at different time instances, have different delay / aging times, and / or include assistance information generated for different reference configuration settings used for the feedback generation parameters. To optimize the TX-based resource selection procedure by taking into account the inter-UE coordinated feedback, the TX UE behavior / procedure on how to process the feedback information should be defined.

[0130] In general, sidelink communication based on TX UE detection and UE-to-UE coordinated feedback may include the following operations.

[0131] Request for UE-to-UE cooperative feedback

[0132] First pre-processing of feedback information at the TX UE (feedback transformation)

[0133] Selection of supporting UEs and UE-to-UE coordinated reporting, which includes filtering of the source of feedback information and filtering of feedback information.

[0134] Feedback applications for TX UE resource selection, including feedback aggregation / combination and resource selection based on TX UE sensing and inter-UE coordinated feedback.

[0135] Depending on the implementation, some of the operations or sub-operations may be skipped or combined into a single processing step. Additionally, the order of the operations may be changed.

[0136] Request for UE-to-UE cooperative feedback

[0137] In the case of unicast or groupcast transmission, the TX UE may explicitly request the generation of UE-to-UE coordinated feedback by the target RX UE. In this case, the TX UE generates an UE-to-UE coordinated feedback request, which may include the following information:

[0138] Number of subchannels L per sidelink preferred / non-preferred resource. The value can also be pre-configured in advance for the UE providing the feedback or a default setting can be assigned.

[0139] Sidelink transmission priority value for resource selection at the assisting UE side. The value can also be pre-configured in advance in the UE providing the feedback or a default setting can be assigned.

[0140] Resource selection window parameters (start time + duration or / end time) for feedback generation or boundary of resource selection window determination. This can be set in subframe / slot / transmission time index (TTI) or can be set to TX UE resource selection window.

[0141] Detection window parameters (start time + duration or / end time) for feedback generation, which may include the minimum detection window required.

[0142] The size of the resource set in % (e.g. the minimum size of a resource set is 5, 10, 20, 30, 40, 50, … N<100% of the resources in the selection window).

[0143] Threshold type and value (e.g., SL-RSRP preferred ,SL-RSRP non-preferred ). This can be used to construct preferred and non-preferred resource sets using SCI decoding and sidelink measurements.

[0144] A resource reservation period or a set of resource reservation periods for feedback generation.

[0145] The reference number of potential future collisions to be taken into account in the feedback generation. This can be a fixed value per periodicity or in any case below a threshold after the end of the window.

[0146] The type of feedback report whether semi-persistent / dynamic transmission or both are used for feedback generation.

[0147] The above values ​​can also be preconfigured in advance in the UE providing the feedback, or a default setting can be assigned. If semi-persistent transmission is performed by the TX UE, the assisted feedback request can be sent just before the upcoming resource reselection event. This time instance is known to the TX UE, so that the feedback provides up-to-date information.

[0148] First pre-processing of feedback information at the TX UE (feedback transformation)

[0149] Based on the information indicated in the feedback, pre-processing of the information at the TX UE may be used prior to feedback selection and further feedback information processing.

[0150] Pre-processing of the information may include:

[0151] Feedback Information Transformation

[0152] If the parameters of the TX UE transmission are different from the parameters used by the assisting UE to generate the feedback, the feedback information may be pre-processed and aligned with the parameters used by the TX UE for detection and resource selection (e.g., the resource size of the TX is different from that used for feedback generation). At least the following procedures may be applied by the TX UE.

[0153] 1) Alignment of resource size (conversion of reference resources in feedback to TX UE resources)

[0154] 2) Alignment of resource selection window (conversion of reference resources in feedback from TX UE resource selection window to resources)

[0155] 3) Alignment of SL-RSRP measurement (if the resources in the feedback are associated with SL-RSRP measurement, additional filtering of the feedback resources can be performed to modify the resource set)

[0156] Example of resource size alignment procedure

[0157] Reference resource size for feedback <TX UE resource size. FIG. 5A shows a resource size alignment procedure according to some embodiments. Resource size alignment procedure. FIG. 5A shows an example in which the reference resource for feedback is composed of L subchannels and resources for transmission of N subchannels, where N = 2L. In this case, the TX resource includes two adjacent feedback resources. If two adjacent feedback resources belong to the resource set, then the adjacent feedback resources can be regarded as TX resources for the same set. FIG. 5B shows another resource size alignment procedure according to some embodiments. In this case, if one of the two adjacent feedback resources belongs to the resource set, then the adjacent feedback resources can be regarded as TX resources for the same set.

[0158] Reference resource size for feedback >TX UE resource size. In this case, any combination of N adjacent subchannels out of L subchannels can be used as a TX resource.

[0159] Selection of supporting UE and UE-to-UE cooperative reporting by TX UE

[0160] The selection of the assisting UE and the UE-to-UE coordinated reporting may be performed in two operations: selecting the UE using the feedback information (filtering the source of the feedback information) and filtering the feedback information. Depending on the implementation, these operations may be combined into a single operation.

[0161] UE Selection Using Feedback Information

[0162] The following set of parameters may be configured to select UEs using the feedback information for further processing.

[0163] Radio coverage (e.g., SL-RSRP coverage) to UEs providing UE-to-UE coordinated feedback (applicable to sensing-based preferred / unpreferred resource sets)

[0164] Location information, which may include distance and / or angular range, as well as other location characteristics (eg, coordinates, altitude, street position, etc.).

[0165] Relative speed / velocity vector for the UE providing UE-to-UE coordinated feedback, which may include, for example, heading relative to the UE providing UE-to-UE coordinated feedback or in absolute terms (North / South / West / East).

[0166] Filtering feedback information

[0167] The following parameters may be used to select the feedback report:

[0168] Feedback source / destination ID and cast type (unicast / groupcast / broadcast)

[0169] Feedback type (dynamic / semi-persistent / both)

[0170] Feedback Delay / Aging Time

[0171] The feedback aging information may be evaluated to decide whether to consider a given feedback or to give priority to the most recent feedback. Option 1: Feedback aging may be evaluated only at the first resource selection (once per Transmission Block (TB) transmission). In this case, the same set of feedback or feedback sources is used to determine the assistance information that may be further used in resource selection. Option 2: Feedback aging value is evaluated at each resource (re)selection / (re)evaluation time. In this case, at each time point, the assistance information source may change in time since the most recent information from a different set of sources may be selected.

[0172] Resource Instructions Window

[0173] Feedback resource selection window (start / end time): Feedback with a resource selection window that overlaps with the TX UE resource selection window that has at least N time resources or a portion of all time resources within the selection window may be selected for further processing.

[0174] Resource reservation period for feedback

[0175] Resource size for generating feedback

[0176] Criteria threshold (type and value)

[0177] Priority values ​​for generating feedback

[0178] Feedback application for TX UE resource selection

[0179] Review of R16 / R17 resource allocation procedures

[0180] FIG. 6 illustrates a block diagram of an NR V2X sidelink resource allocation procedure according to some embodiments. In FIG. 6, the sensed data is processed and the transmission S is allocated with the exception of reserved resources within the resource selection window. A Next, we form a TX-based candidate resource set for the set R S N resources for potential transmission are selected, denoted by N. These resources are re-evaluated by using the most recent sensing information to finally determine the resources to be used for transmission and reservation.

[0181] Solutions for considering R16 / R17 resource allocation procedures

[0182] FIG. 7A illustrates a block diagram of a first option of a NR V2X sidelink resource allocation procedure with UE-to-UE coordinated feedback according to some embodiments. FIG. 7B illustrates a block diagram of a second option of a NR V2X sidelink resource allocation procedure with UE-to-UE coordinated feedback according to some embodiments. FIG. 7C illustrates a block diagram of a third option of a NR V2X sidelink resource allocation procedure with UE-to-UE coordinated feedback according to some embodiments. FIG. 7D illustrates a block diagram of a fourth option of a NR V2X sidelink resource allocation procedure with UE-to-UE coordinated feedback according to some embodiments. FIG. 7E illustrates a block diagram of a fifth option of a NR V2X sidelink resource allocation procedure with UE-to-UE coordinated feedback according to some embodiments. FIG. 7F illustrates a block diagram of a sixth option of a NR V2X sidelink resource allocation procedure with UE-to-UE coordinated feedback according to some embodiments. FIG. 7G illustrates a block diagram of a seventh option of a NR V2X sidelink resource allocation procedure with UE-to-UE coordinated feedback according to some embodiments.

[0183] One difference between these options is the procedure in which the resource set provided by the UE-to-UE cooperative feedback is taken into account for resource selection. In particular, in option 1 (FIG. 7A), the UE-to-UE cooperative feedback information (resource set S B ) is the resource exclusion and candidate resource set S C In option 2 (FIG. 7B), the UE-to-UE cooperative feedback information (resource set S B ) is a resource set R S In option 3 (FIG. 7C), the UE-to-UE cooperative feedback information (resource set S B ) is the resource exclusion and candidate resource set S C and the formation of the resource set R S In option 4 (FIG. 7D), the UE-to-UE cooperative feedback information (resource set S B ) is a resource set R TX / RSV In option 5 (FIG. 7E), the UE-to-UE cooperative feedback information (resource set S B ) is the candidate resource set S C and resource exclusion to form the resource set R TX / RSV In option 6 (FIG. 7F), the UE-to-UE cooperative feedback information (resource set S B ) is the candidate resource set R S The initial resource selection to form the resource set R TX / RSV In option 7 (FIG. 7G), the UE-to-UE cooperative feedback information (resource set S B ) is the resource exclusion and candidate resource set S C To form the candidate resource set R S For the initial resource selection to form the resource set R TX / RSV Used for resource re-evaluation to generate

[0184] UE Collaborative Feedback Content

[0185] The supporting UE may report the following information in the inter-UE coordinated feedback message to assist the TX UE in resource selection:

[0186] Identified preferred resource set - set S B-P (recommended time-frequency or time resources from the RX UE perspective within a resource pool and time interval).

[0187] Identified set of undesirable resources - set S B-NP (Time-frequency or time resources that are not recommended from the RX UE point of view within a resource pool and time interval). A set of unpreferred resources S B-NP can be divided into two resource subsets: resource set S B1-NP , which are resources determined by the supporting UE based on the radio sensing and resource exclusion / selection procedure, and may be constructed according to the sensing and resource exclusion procedure of R16; and resource set S B2-NP , which are resources selected or reserved by the supporting UE for potential sidelink or uplink transmissions that impact the UE sidelink reception capability.

[0188] The value of the resource selection metric threshold (e.g., SL-RSRP threshold, distance threshold) associated with each reported resource set. If a fixed threshold is set in the assisting UE (i.e., not updated by the assisting UE), this information does not need to be reported. If the initial threshold value is set by the assisting UE and further incremented / decremented for resource set identification, then the updated threshold used to generate the reported resource set may also be reported back to the TX UE.

[0189] Resource selection metrics (e.g., SL-RSRP measurements, distance) associated with identified resources of each resource set. If the assisting UE is the target receiver UE, the resource selection metrics are meaningful for resource selection at the TX UE side. The SL-RSRP of simultaneous transmissions measured at the target RX UE can potentially be used to estimate the communication link quality and determine the feasibility of transmission on a particular resource, with a notion of interference power that can help adjust the transmission parameters. If the assisting UE is not the target receiver UE, the resource selection metrics from this UE can be achieved with additional information (e.g., distance, SL-RSRP measurements) that characterize the assisting UEs in the vicinity of the target receiver. This additional information can be used to characterize the environment of the target receiver.

[0190] Once the feedback with preferred and non-preferred resource sets has been pre-processed, it may be used in the final resource selection procedure using one of two alternatives: Alternative 1: Independent feedback processing for resource exclusion / (re)selection / (re)evaluation. In this case, the preferred (and / or non-preferred) resource sets signaled in each feedback may be processed independently. Alternative 2: Feedback combination / aggregation for resource exclusion / (re)selection / (re)evaluation. In this case, the preferred (and / or non-preferred) resource sets may be aggregated via multiple pre-selected feedback reports.

[0191] Resource Set FeedbackResource Set Combination / Aggregation

[0192] Scenario 1: Only resources are reported, without any additional associated metrics (e.g., SL-RSRP, distance).

[0193] In this case, multiple alternatives for generating the combined resource set may be used.

[0194] Alternative 1: The combined resource set is the intersection of the input resource sets.

number

[0195] Alternative 2: The combined resource set is a combination of the input resource sets.

number

[0196] Alternative 3: The combined resource set is generated based on resource occurrence. For each resource, the resource occurrence in the report can be estimated and used to determine whether a particular resource should be included (or excluded) in the combined resource set. For example, if a pre-defined threshold ≧ Thr B Only resources with an occurrence rate above Thr may be included in the combined resource set. B is a preconfigured threshold used to determine whether a resource is included (or excluded) from the combined resource set.

[0197] Scenario 2: The reported resources are associated with additional metrics (eg, SL-RSRP, distance).

[0198] In this case, resources whose reported additional resource metrics are below (e.g., SL-RSRP for a preferred resource set) or above (e.g., SL-RSRP for a non-preferred resource set) a (pre-)configured threshold may be included (or excluded) in the combined resource set.

[0199] In a further embodiment, the TX UE may estimate and apply a threshold for estimating resource generation for a given metric threshold.

[0200] Determining the type of preferred / non-preferred resources based on processing multiple feedbacks received by the TX UE (feedback report-resource set combinations)

[0201] A set of resources S based on cooperative feedback among UEs B The formation of depends on the classification of the reported resource, ie, whether the resource can be considered preferred or non-preferred.

[0202] A number of options may be used to determine the non-preferred resource based on processing of multiple feedback transmissions received by the TX UE.

[0203] When a resource set is reported without any additional metrics (SL-RSRP, distance), the reported resource R x,y is considered objectionable if:

[0204] Scenario 1: Resource sets from different sources (supporting UEs) are processed separately and R x,y is the selected assistant UE k Unfavorable resources received from S B-NP-k UE1..UE2., and Rx,y are members of the assistant UE [UE1..UE K Unfavorable resource set [S B-NP-1 ..S B-NP-K ] at least one set S B-NP-k Member of R x,y assistant UE [UE1..UE K Unfavorable resource set [S B-NP-1 ..S B-NP-K ] and R x,y assistant UE [UE1..UE K Unfavorable resource set [S B-NP-1 ..S B-NP-K ] are N members of K sets in

[0205] Scenario 2: Resource sets from different sources (supporting UEs) are aggregated / combined. x,y is the combined set of unfavorable resources S B-NP-Combined When a resource set and corresponding additional metrics are reported, the reported resource R x,y is considered objectionable if:

[0206] Scenario 1: Resource sets from different sources are treated separately. Selected Assistant UE k Unfavorable resources received from S B-NP-k The associated resource R in the set x,y Support metric M Rx,y-k >M Thr Assistant UE [UE1..UE K Unfavorable resource set [S B-NP-1 ..S B-NP-K ] at least one set S B-NP-k Associated resource R in x,y Support metric M Rx,y-k >M Thr Assistant UE [UE1..UE K Unfavorable resource set [S B-NP-1 ..S B-NP-K ], the associated reported assistance metric M Rx,y-k >M Thr Assistant UE [UE1..UE K Unfavorable resource set [S B-NP-1 ..S B-NP-K ], the associated reported assistance metrics M Rx,y-k >M Thr .

[0207] Scenario 2: Resource sets from different sources are aggregated. Assistant UE k Unfavorable resources received from S B-NP-k The associated reported assistance metric MRx,y-Combined >M Thr The above procedure may also be applied to determine a preferred resource based on processing coordinated feedback between multiple UEs.

[0208] Resource exclusion based on unpreferred resource set and TX-based detection to form candidate resource set for resource selection

[0209] In this section, a modification of the resource exclusion procedure that takes into account the UE-to-UE coordinated feedback from the supporting UE is described. In the legacy operation, the UE uses the sensing result, as determined via the resource exclusion procedure, to select a candidate resource set S, which is used for further selection of candidate resources for transmission. A 8A illustrates a procedure for removing resources not using an inter-UE coordinated resource set according to some embodiments.

[0210] When feedback is provided, the TX UE may generate two or more sets (up to N) of resources: set S A : A set of resources after resource exclusion is applied to the TX UE sensed data (a set of candidate resources); set S B : A set of resources from UE cooperative feedback; set S B-k :UE k A set of UE-to-UE cooperative feedback resources from (k=1 for single UE or aggregated reporting process); a set S C ; Resource exclusion is based on the TX UE sensed data and the undesired resource set (set S B-k ), the set of resources (the set of candidate resources). Set S B-k may be generated using the preferred and / or non-preferred resource sets. x,y If a resource is classified as undesirable, then the resource is placed in the set S B-k Otherwise, if the resource is classified as preferred, then the resource should not be added or should not be added to set SB-k It should be removed from

[0211] The following options can be used to enhance the resource exclusion procedure:

[0212] Option 1: Unfavourable resource-set S from UE-to-UE coordinated feedback B (or set S B-k ) is included in the resource candidate resource set S regardless of the result of the resource exclusion procedure for processing the TX detection result, as shown in FIG. 8B. A 8B illustrates a resource exclusion procedure using an inter-UE coordinated resource set according to some embodiments.

[0213] Option 2: The TX detection result is the candidate resource set S A 8C illustrates another resource exclusion procedure using inter-UE coordinated resource sets according to some embodiments. C-k To obtain the candidate resource set, the candidate resource set is further divided into a non-preferred or preferred resource set S B-k Finally, as shown in FIG. 8C, the candidate resource set S C To generate a set of all candidate resources S C-k (Optionally, the TX candidate resource set S A Set S A is S C-k The final set S after combining C If is too small, set S A is used as a fallback option or is added at the last stage to ensure that resources can at least be borrowed from this set.

[0214] Option 3: The TX detection result is the candidate resource set S A8D illustrates another resource exclusion procedure using inter-UE coordinated resource sets according to some embodiments. As shown in FIG. 8D, the UE / feedback specific candidate resource set S C To obtain the candidate resource set, the candidate resource set is further divided into a non-preferred or preferred resource set S B Set S B is multiple feedback S B-k During the final combination, the combined set S C If is too small, set S A can be used as a fallback (i.e., in the set S C = Set S A ) or Set S A The resources from the resource set S C can be borrowed at least to form

[0215] Although the embodiments have been described with reference to certain exemplary embodiments, it will be apparent that various modifications and changes can be made to these embodiments without departing from the broader scope of the present disclosure. Thus, the specification and drawings should be regarded in an illustrative and not restrictive sense. The accompanying drawings, which form a part of this application, show, by way of example and not limitation, specific embodiments in which the subject matter may be practiced. The illustrated embodiments are described in sufficient detail to enable those skilled in the art to practice the teachings disclosed herein. Other embodiments may be utilized and derived therefrom, such that structural and logical substitutions and changes may be made without departing from the scope of the present disclosure. Thus, this detailed description should not be construed in a limiting sense, and the scope of the various embodiments is defined solely by the appended claims, including the full scope of equivalents to which such claims are entitled.

[0216] The subject matter may be referred to herein by the term "embodiments", individually and / or collectively, merely for convenience and without the intention of intentionally limiting the scope of the present application to any single inventive concept when more than one inventive concept is actually disclosed. Thus, although multiple specific embodiments are shown and described herein, it should be understood that any configuration intended to achieve the same purpose may be substituted for the multiple specific embodiments shown. The present disclosure is intended to cover any and all adaptations or variations of the various embodiments. Combinations of the above embodiments, as well as other embodiments not specifically described herein, will be apparent to one of ordinary skill in the art upon reviewing the above description.

[0217] In this document, the terms "a" or "an" are used to include one or more than one, as is common in patent documents, independent of any other instance or use of "at least one" or "one or more." In this document, the term "or" is used to refer to a non-exclusive, or "A or B" is used to include "A but not B," "B but not A," and "A and B," unless otherwise stated. In this document, the terms "including" and "in which" are used as the plain-language equivalents of the respective terms "comprising" and "wherein." Also, in the following claims, the terms "including" and "comprising" are open-ended, i.e., a system, UE, article, composition, formula, or process that includes multiple elements in addition to those recited after such term in a claim is still considered to be within the scope of that claim. Moreover, in the following claims, the terms "first," "second," and "third," etc. are used merely as labels and are not intended to impose numerical requirements on their objects.

[0218] The Abstract of the Disclosure is provided to comply with 37 CFR §1.72(b), which requires an abstract that will allow the reader to quickly ascertain the nature of the technical disclosure. The Abstract is submitted with the understanding that it will not be used to interpret or limit the scope or meaning of the claims. Moreover, in the foregoing Detailed Description, it will be seen that various features have been grouped together in a single embodiment for the purpose of streamlining the disclosure. This method of disclosure should not be interpreted as reflecting an intention that the claimed embodiments require more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive subject matter consists of less than all features of a single disclosed embodiment. Thus, the following claims are hereby incorporated into the Detailed Description, with each claim standing on its own as a separate embodiment.

Claims

1. A device for user equipment (UE), wherein the device is Receiving requests from other UEs for inter-UE collaborative feedback, including at least one of a preferred resource set and a non-preferred resource set for vehicle-to-everything (V2X) side-link communication; Determining whether the inter-UE collaborative feedback is permitted to be transmitted to the other UE as standalone inter-UE collaborative feedback transmitted separately from other sidelink transmissions to the other UE, or whether the inter-UE collaborative feedback is permitted to be transmitted to the other UE only as non-standalone inter-UE collaborative feedback transmitted together with data to the other UE; and Transmitting the inter-UE collaborative feedback to the other UE, depending on the decision of whether the inter-UE collaborative feedback is permitted to be transmitted to the other UE as standalone inter-UE collaborative feedback or only as non-standalone inter-UE collaborative feedback. A processing circuit configured to configure the UE to perform the following; and A memory configured to store the aforementioned inter-UE cooperative feedback. Equipped with, The request comprises parameters for transmitting the inter-UE cooperative feedback, The parameter includes a time interval after the receipt of the request for the transmission of the inter-UE cooperative feedback, The time interval following the receipt of the request is time-aligned with the resource reselection activity of the other UE. In response to receiving the request, the processing circuit further configures the UE to transmit inter-UE cooperative feedback to the other UE during the time interval following the receipt of the request.

2. An apparatus for user equipment (UE), wherein the apparatus is Receiving requests from other UEs for inter-UE collaborative feedback, including at least one of a preferred resource set and a non-preferred resource set for vehicle-to-everything (V2X) side-link communication; Determining whether the inter-UE collaborative feedback is permitted to be transmitted to the other UE as standalone inter-UE collaborative feedback transmitted separately from other sidelink transmissions to the other UE, or whether the inter-UE collaborative feedback is permitted to be transmitted to the other UE only as non-standalone inter-UE collaborative feedback transmitted together with data to the other UE; and Transmitting the inter-UE collaborative feedback to the other UE, depending on the decision of whether the inter-UE collaborative feedback is permitted to be transmitted to the other UE as standalone inter-UE collaborative feedback or only as non-standalone inter-UE collaborative feedback. A processing circuit configured to configure the UE to perform the following; and A memory configured to store the aforementioned inter-UE cooperative feedback. Equipped with, The processing circuit further prioritizes sidelink transmissions, including inter-UE cooperative feedback, among different cast types, and A device that configures the UE to set a higher priority for sidelink transmission using inter-UE cooperative feedback than for sidelink transmission without inter-UE cooperative feedback.

3. The apparatus according to claim 2, wherein the cast type includes broadcast transmission, group cast transmission, and unicast transmission.

4. An apparatus for a user equipment (UE), wherein the apparatus is Receiving requests from other UEs for inter-UE collaborative feedback, including preferred and unpreferred resource sets for vehicle-to-everything (V2X) side-link communication; Determining whether the inter-UE collaborative feedback is permitted to be transmitted to the other UE as standalone inter-UE collaborative feedback transmitted separately from other sidelink transmissions to the other UE, or whether the inter-UE collaborative feedback is permitted to be transmitted to the other UE only as non-standalone inter-UE collaborative feedback transmitted together with data to the other UE; and Transmitting the inter-UE collaborative feedback to the other UE, depending on the decision of whether the inter-UE collaborative feedback is permitted to be transmitted to the other UE as standalone inter-UE collaborative feedback or only as non-standalone inter-UE collaborative feedback. A processing circuit configured to configure the UE to perform the following; and A memory configured to store the aforementioned inter-UE cooperative feedback. Equipped with, The processing circuit is further configured to configure the UE to transmit the content of the inter-UE cooperative feedback which depends on the cast type, the cast type being selected from a group of cast types including broadcast transmission, group cast transmission, and unicast transmission. The processing circuit further configures the UE to select the content from a set of content including header information; preferred resource set (set 1); unpreferred resource set (set 2); reference resource size; sizes of sets 1 and 2; reference signal received power (SL-RSRP), channel quality index (CQI), or distance thresholds and values ​​for sets 1 and 2; reference priority; resource selection window or start slot index of the reported resource set; start and end of detection window; detection parameters; at least one of sidelink transmit or receive pool identifier (ID); dynamic transmit considered for feedback; semi-persistent transmit considered for feedback; set of resource reservation periods; and at least one of source or destination ID.

5. The apparatus according to any one of claims 1 to 4, wherein the processing circuit further configures the UE to transmit the inter-UE coordinating feedback using a medium access control (MAC) control element (MAC-CE) on a physical sidelink shared channel (PSSCH), and the inter-UE coordinating feedback multiplexed with the data in response to the determination that the inter-UE coordinating feedback is the non-standalone inter-UE coordinating feedback.

6. The apparatus according to any one of claims 1 to 4, wherein the processing circuit further configures the UE to transmit the inter-UE cooperative feedback for avoiding sidelink contention in at least one container of sidelink control information (SCI) format 2 (stage 2), media access control (MAC) control element (MAC-CE), or PC5 radio resource control (RRC) signaling, or distributed across multiple containers.

7. A computer program comprising instructions for execution by one or more processors of a user device (UE), wherein when the instructions are executed, Receiving requests from other UEs for inter-UE collaborative feedback, including at least one of a preferred resource set and a non-preferred resource set for vehicle-to-everything (V2X) side-link communication; Determining whether the inter-UE collaborative feedback is permitted to be transmitted to the other UE as standalone inter-UE collaborative feedback transmitted separately from other sidelink transmissions to the other UE, or whether the inter-UE collaborative feedback is permitted to be transmitted to the other UE only as non-standalone inter-UE collaborative feedback transmitted together with data to the other UE; and Transmitting the inter-UE collaborative feedback to the other UE, depending on the decision of whether the inter-UE collaborative feedback is permitted to be transmitted to the other UE as standalone inter-UE collaborative feedback or only as non-standalone inter-UE collaborative feedback. The UE is configured to perform the following: The request comprises parameters for transmitting the inter-UE cooperative feedback, The parameter includes a time interval after the receipt of the request for the transmission of the inter-UE cooperative feedback, The time interval following the receipt of the request is time-aligned with the resource reselection activity of the other UE. A computer program in which, in response to receiving the request, the one or more processors further configure the UE to send inter-UE cooperative feedback to the other UEs during the time interval after receiving the request when the instruction is executed.

8. A computer program comprising instructions for execution by one or more processors of a user device (UE), wherein when the instructions are executed, Receiving requests from other UEs for inter-UE collaborative feedback, including at least one of a preferred resource set and a non-preferred resource set for vehicle-to-everything (V2X) side-link communication; Determining whether the inter-UE collaborative feedback is permitted to be transmitted to the other UE as standalone inter-UE collaborative feedback transmitted separately from other sidelink transmissions to the other UE, or whether the inter-UE collaborative feedback is permitted to be transmitted to the other UE only as non-standalone inter-UE collaborative feedback transmitted together with data to the other UE; and Transmitting the inter-UE collaborative feedback to the other UE, depending on the decision of whether the inter-UE collaborative feedback is permitted to be transmitted to the other UE as standalone inter-UE collaborative feedback or only as non-standalone inter-UE collaborative feedback. The UE is configured to perform the following: The one or more processors further prioritize sidelink transmissions, including inter-UE cooperative feedback, among different cast types when the instruction is executed, and A computer program that configures the UE to set a higher priority for sidelink transmission using inter-UE cooperative feedback than for sidelink transmission without inter-UE cooperative feedback.

9. A computer program comprising instructions for execution by one or more processors of a user device (UE), wherein when the instructions are executed, Receiving requests from other UEs for inter-UE collaborative feedback, including preferred and unpreferred resource sets for vehicle-to-everything (V2X) side-link communication; Determining whether the inter-UE collaborative feedback is permitted to be transmitted to the other UE as standalone inter-UE collaborative feedback transmitted separately from other sidelink transmissions to the other UE, or whether the inter-UE collaborative feedback is permitted to be transmitted to the other UE only as non-standalone inter-UE collaborative feedback transmitted together with data to the other UE; and Transmitting the inter-UE collaborative feedback to the other UE, depending on the decision of whether the inter-UE collaborative feedback is permitted to be transmitted to the other UE as standalone inter-UE collaborative feedback or only as non-standalone inter-UE collaborative feedback. The UE is configured to perform the following: The one or more processors further configure the UE to transmit the content of the inter-UE cooperative feedback, which depends on the cast type, when the instruction is executed, the cast type is selected from a group of cast types, which include broadcast transmission, group cast transmission, and unicast transmission. The computer program further configures the UE to select the content from a set of content including, when the instruction is executed, header information; preferred resource set (set 1); unpreferred resource set (set 2); reference resource size; sizes of sets 1 and 2; reference signal reception power (SL-RSRP), channel quality index (CQI), or distance thresholds and values ​​for sets 1 and 2; reference priority; resource selection window or start slot index of the reported resource set; start and end of detection window; detection parameters; at least one of sidelink transmission or receive pool identifier (ID); dynamic transmission considered for feedback; semi-persistent transmission considered for feedback; set of resource reservation periods; and at least one of source or destination ID.

10. A computer-readable storage medium for storing a computer program according to any one of claims 7 to 9.

Images