Offloading sidelink scheduling to reduce user equipment power consumption

Abstract

A user equipment (UE) is configured to transmit a scheduling request (SR) to a second UE, causing the second UE to determine a set of sidelink transmission resources for use by the UE. The UE then receives information from the second UE regarding the determined set of sidelink transmission resources and may then transmit sidelink communications using at least a subset of the determined set of sidelink transmission resources. The determined set of sidelink transmission resources may be recommended and reserved or unreserved resources. The UE may transmit configuration information to the second UE regarding the transmission resources to be used when transmitting the SR. The second UE may monitor the channel for arriving resources. The SR may be coded as a cyclic shift of the SR, corresponding to an ACK-only sequence, an ACK / NACK sequence, or a sequence of SRs based on a configuration index.

Description

[Technical field]

[0001] The present application relates to wireless devices, and more particularly to apparatus, systems, and methods for scheduling and allocating sidelink resources for wireless devices with varying power capabilities to reduce latency and power consumption, and improve reliability. [Background technology]

[0002] The use of wireless communication systems is growing rapidly. One proposed use of wireless communication is in vehicular applications, particularly in V2X (Vehicle to Everything) systems. V2X systems enable communication between vehicles (e.g., via communication devices housed within or otherwise carried by the vehicles), pedestrian UEs (including UEs carried by other people, such as cyclists), and other wireless communication devices for various purposes, such as coordinating traffic activities, facilitating autonomous driving, and performing collision avoidance.

[0003] Certain V2X systems have increased communication requirements that can tax the power and resource capabilities of portable, battery-powered UE devices. In addition, some UEs are more power constrained than others, and communicating with the UE's host can exhibit reduced battery life, increased latency, and exacerbated communication problems. Thus, improvements in this area are desirable. Summary of the Invention

[0004] Presented herein are embodiments of an apparatus, system, and method for a wireless device to offload scheduling and allocation of sidelink resources to another higher power wireless device for reduced latency and power consumption, and improved reliability.

[0005] Some embodiments relate to a user equipment (UE) comprising at least one antenna, a radio operatively coupled to the at least one antenna, and a processor operatively coupled to the radio. The UE (first UE) may be configured to transmit a scheduling request to the second UE causing the second UE to determine a set of sidelink transmission resources for use by the first UE. In other words, the first UE may offload the task of determining available sidelink resources of the first UE to the second UE, which may have a higher power capability compared to the first UE. In response to the scheduling request, the second UE may determine a set of available sidelink resources for use by the first UE, for example, by sensing traffic on a sidelink channel. The second UE may then provide these determined sidelink resources to the first UE. In some aspects, the second UE may monitor this channel for the arrival of these resources. Thus, the first UE may receive information from the second UE regarding the determined set of sidelink transmission resources, which set of sidelink resources was determined by the second UE based on the transmitted scheduling request. Finally, the first UE may transmit sidelink communication using at least a subset of the determined set of sidelink transmission resources indicated by the second UE.

[0006] In some aspects, the determined set of sidelink transmission resources may be recommended (non-reserved) resources, whereas in other aspects, the determined set of sidelink transmission resources may be reserved by the second UE for use by the first UE.

[0007] Furthermore, one or both of the first and second UEs may be further configured to exchange configuration information with the other, the configuration information configuring transmission resources to be used when transmitting the scheduling request.

[0008] The sidelink scheduling request (S-SR) may be encoded as a cyclic shift of the S-SR corresponding to an ACK-only sequence or an ACK / NACK sequence. In some embodiments, the scheduling request may be encoded as a configuration index that points to one sequence of S-SR.

[0009] Some embodiments may relate to a user equipment (UE) device having at least one antenna for performing wireless communication, a radio, and a processing element coupled to the radio. The UE may perform at least some of the methods described herein.

[0010] Some embodiments relate to a baseband processor having processing circuitry configured to perform at least some or all of the above operations.

[0011] This Summary is intended to provide a brief overview of some of the subject matter described in this document. It should therefore be understood that the above features are merely examples and should not be construed as narrowing the scope or spirit of the subject matter described herein. Other features, aspects, and advantages of the subject matter described herein will become apparent from the following detailed description, drawings, and claims. [Brief description of the drawings]

[0012] A better understanding of the present subject matter may be obtained from the following detailed description of various embodiments when considered in conjunction with the following drawings.

[0013] [Figure 1] FIG. 1 illustrates an example of a vehicle-to-everything (V2X) communication system, according to some embodiments.

[0014] [Diagram 2] FIG. 1 illustrates a base station in communication with a user equipment (UE) device, according to some embodiments.

[0015] [Diagram 3]FIG. 2 illustrates an example block diagram of a UE, in accordance with some embodiments.

[0016] [Figure 4] FIG. 2 illustrates an example block diagram of a base station according to some embodiments.

[0017] [Diagram 5] FIG. 1 illustrates an example of a vehicle-to-everything network, according to some embodiments.

[0018] [Figure 6] A diagram illustrating an example procedure for slave UE data transmission according to some embodiments.

[0019] [Figure 7] FIG. 1 illustrates an example procedure for master UE data transmission, according to some embodiments.

[0020] [Figure 8] FIG. 1 illustrates an example structure of a Sidelink Scheduling Request (S-SR) signal according to some embodiments.

[0021] [Figure 9] FIG. 1 illustrates frequency and code resources for a Sidelink Scheduling Request (S-SR) signal according to some embodiments.

[0022] [Figure 10] FIG. 2 illustrates an example of how a master UE provides recommended but unreserved resources to a slave UE, according to some embodiments.

[0023] [Figure 11] FIG. 2 illustrates an example of how a master UE provides recommended and reserved resources to a slave UE, according to some embodiments.

[0024] While the features described herein are susceptible to various modifications and alternative forms, specific embodiments thereof have been shown by way of example in the drawings and are herein described in detail. It should be understood, however, that the drawings and detailed description are not intended to limit the invention to the particular forms disclosed, but rather to cover all modifications, equivalents, and alternatives within the spirit and scope of the present subject matter as defined by the appended claims. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0025] term Various acronyms are used throughout this disclosure. Definitions of the most prominently used acronyms that may appear throughout this disclosure are provided below: ●UE: User Equipment ●RF: Radio Frequency ●BS: Base station ●GSM: Global System for Mobile Communications ●UMTS: Universal Mobile Telecommunications System ●LTE: Long Term Evolution ●NR: New Radio ●NR-U: License-free NR ● TX: Send / Transmit ● RX: Receive / Receive RAT: Radio Access Technology ●TRP: Transmitting / receiving point DCI: Downlink control information ●V2X: Vehicle to Everything PSCCH: Physical Sidelink Control Channel PSSCH: Physical Sidelink Shared Channel ●PUCCH: Physical uplink control channel S-SR: Sidelink Scheduling Request ●PUE: Pedestrian User Equipment ●VUE: Vehicle User Equipment ●SL: Side link ●MCS: Modulation and coding scheme ●DMRS: Demodulation Reference Signal ●RO: Resource Occupation ●RSU: Roadside Unit ●SPS: Semi-persistent scheduling ●QoS: Quality of Service

[0026] The following is a description of terms used in this disclosure:

[0027] Memory medium - any of various types of non-transitory memory or storage devices. The term "memory medium" is intended to include, for example, installation media such as CD-ROM, floppy disk, or tape devices; computer system memory or random access memory such as DRAM, DDR RAM, SRAM, EDO RAM, Rambus RAM; non-volatile memory such as flash, magnetic media such as hard drives, or optical storage; registers, or other similar types of memory elements; and the like. The memory medium may also include other types of non-transitory memory, or may include combinations thereof. In addition, the memory medium may be located in a first computer system where the program is executed, or in a second, different computer system that connects to the first computer system via a network such as the Internet. In the latter case, the second computer system may provide the program instructions to the first computer for execution. The term "memory medium" may include two or more memory media that may exist in different locations, for example, in different computer systems connected via a network. The memory medium may store program instructions (e.g., embodied as a computer program) that may be executed by one or more processors.

[0028] Programmable Hardware Element - includes a variety of hardware devices with multiple programmable function blocks connected via programmable interconnects. Examples include Field Programmable Gate Arrays (FPGAs), Programmable Logic Devices (PLDs), Field Programmable Object Arrays (FPOAs), and Complex PLDs (CPLDs). Programmable function blocks can range from fine-grained (combinational logic or look-up tables) to coarse-grained (arithmetic logic units or processor cores). Programmable hardware elements may also be referred to as "reconfigurable logic."

[0029] Computer System - any of various types of computing or processing systems, including a personal computer system (PC), a mainframe computer system, a workstation, a network appliance, an Internet appliance, a personal digital assistant (PDA), a television system, a grid computing system, or any other device or combination of devices. In general, the term "computer system" can be broadly defined to encompass any device (or combination of devices) having at least one processor that executes instructions from a memory medium.

[0030] User Device - as used herein, in the context of a V2X system, may generally refer to devices associated with mobile actors or traffic participants in a V2X system, i.e., mobile (movable) communication devices such as vehicles and pedestrian user equipment (PUE) devices, as opposed to infrastructure devices such as base stations, roadside units (RSUs), and servers.

[0031] Infrastructure Device - as used herein, in the context of a V2X system, may generally refer to a particular device in the V2X system that is not a user device and is not carried by a traffic actor (i.e., a pedestrian, vehicle, or other mobile user), but that facilitates the participation of user devices in the V2X network. Infrastructure devices include base stations and roadside units (RSUs).

[0032] User Equipment (UE) (or "UE device") - any of a variety of mobile or handheld computing system devices that perform wireless communications. Examples of UE devices include mobile phones or smartphones (e.g., iPhone™, Android™ based phones), portable gaming devices (e.g., Nintendo DS™, PlayStation Portable™, Gameboy Advance™, iPhone™), laptops, wearable devices (e.g., smart watches, smart glasses), PDAs, portable Internet devices, music players, data storage devices, or other handheld devices. In general, the term "UE" or "UE device" can be broadly defined to encompass any electronic, computing and / or telecommunications device (or combination of devices) that is easily carried by a user and capable of wireless communications.

[0033] Pedestrian UE (PUE) Device - A User Equipment (UE) device that may be worn or carried by a variety of people, including pedestrians in the strict sense of a person walking near a road, but also other peripheral or minor participants or potential participants in a traffic environment. These include people who are stationary, not necessarily near traffic or roads, not in a vehicle, jogging, running, skating, etc., or in a vehicle that does not substantially increase the power capabilities of the UE, such as a bicycle, scooter, or some type of automobile. Examples of pedestrian UE include smartphones, wearable UEs, PDAs, etc.

[0034] Base Station - The term "base station" has the full scope of its ordinary meaning and includes at least a wireless communication station that is installed at a fixed location and used for communication as part of a wireless telephone or wireless system.

[0035] Processing Element - refers to various elements or combinations of elements. Processing elements include, for example, a circuit such as an Application Specific Integrated Circuit (ASIC), a portion or circuit of an individual processor core, an entire processor core, an individual processor, a programmable hardware device such as a field programmable gate array (FPGA), and / or a larger portion of a system including multiple processors.

[0036] Channel - a medium used to convey information from a sender (transmitter) to a receiver. Note that since the characteristics of the term "channel" may differ according to different wireless protocols, as used herein, the term "channel" is deemed to be used consistent with the standard of the type of device with which the term is used in association. In some standards, the channel width may be variable (e.g., depending on device capabilities, band conditions, etc.). For example, LTE may support scalable channel bandwidths from 1.4 MHz to 20 MHz. In contrast, a WLAN channel may have a 22 MHz width and a Bluetooth channel may have a 1 Mhz width. Other protocols and standards may include different channel definitions. Additionally, some standards may define and use multiple types of channels, e.g., different channels for uplink or downlink, and / or different channels for different uses of data, control information, etc. Figure 1-V2X communication system

[0037] 1 illustrates an exemplary vehicle-to-everything (V2X) communications system according to some embodiments. It should be noted that the system of FIG. 1 is merely one example of a possible system, and features of the present disclosure may be implemented in any of a variety of systems as desired.

[0038] A vehicle-to-everything (V2X) communication system may be characterized as a network in which vehicles, UEs, and / or other devices and network entities exchange communications to coordinate traffic activities, among other possible purposes. V2X communications include communications conveyed between vehicles (e.g., wireless or communication devices that form part of, are included in, or are otherwise carried by, the vehicle) and various other devices. V2X communications include vehicle-to-pedestrian (V2P), vehicle-to-infrastructure (V2I), vehicle-to-network (V2N), and vehicle-to-vehicle (V2V) communications, as well as communications between vehicles and other possible network entities or devices. V2X communications may also refer to communications between other non-vehicle devices that participate in the V2X network for the purpose of sharing V2X-related information.

[0039] V2X communications may conform to, for example, the 3GPP Cellular V2X (C-V2X) specification or one or more other or subsequent standards in which vehicles and other devices and network entities may communicate. V2X communications may utilize both long-range (e.g., cellular) and short- to medium-range (e.g., non-cellular) communications. Cellular-enabled V2X communications may be referred to as Cellular V2X (C-V2X) communications. C-V2X systems may use a variety of cellular radio access technologies (RATs), such as 4G LTE or 5G NR RATs. Certain LTE standards that may be used in V2X systems may be referred to as LTE-Vehicle (LTE-V) standards.

[0040] As shown in the figure, the exemplary V2X system includes several user devices. As used herein in the context of a V2X system and as defined above, the term "user device" may generally refer to devices associated with mobile actors or traffic participants in a V2X system, i.e., mobile (movable) communication devices such as vehicles and pedestrian user equipment (PUE) devices. The user devices in the exemplary V2X system include PUEs 104A and 104B and vehicles 106A and 106B.

[0041] Vehicle 106 may comprise various types of vehicles. For example, vehicle 106A may be a road vehicle or automobile, a mass transit vehicle, or another type of vehicle. Vehicle 106 may communicate wirelessly by various means. For example, vehicle 106A may include communication equipment as part of or housed in the vehicle, or may communicate through a wireless communication device currently included in the vehicle or otherwise carried by the vehicle, such as a user equipment (UE) device (e.g., a smartphone or similar device) carried or worn by a driver, passenger, or other person aboard the vehicle, among other possibilities. For simplicity, the term "vehicle" as used herein refers to the vehicle and may include the wireless communication equipment that carries the communication. Thus, for example, when vehicle 106A is said to carry wireless communication, it is understood that more specifically, a particular wireless communication equipment associated with and carried by vehicle 106A is carrying the wireless communication.

[0042] Pedestrian UE (PUE) 104 may constitute various types of user equipment (UE) devices, i.e., portable devices capable of wireless communication, such as smartphones, smart watches, etc., and may be associated with various types of users. Thus, PUE 104 is a UE and may be referred to as a UE or a UE device. It should be noted that although UE 104 may be referred to as a PUE (pedestrian UE), they are not necessarily carried by a person actively walking near a road or street. PUE may refer to a UE participating in a V2X system and carried by a person standing still, walking or running, or riding in a vehicle that may not substantially increase the power capabilities of the device, such as a bicycle, scooter, or some type of automobile. It should also be noted that not all UEs participating in a V2X system are necessarily PUEs.

[0043] A user device may be capable of communicating using multiple wireless communication standards. For example, the UE 104A may be configured to communicate using wireless networking (e.g., Wi-Fi) and / or peer-to-peer wireless communication protocols (e.g., Bluetooth, Wi-Fi peer-to-peer, etc.) in addition to at least one cellular communication protocol (e.g., GSM, UMITS, LTE, LTE-A, LTE-V, HSPA, 3GPP2 CDMA2000, 5G NR, etc.). The UE 104A may additionally or alternatively be configured to communicate using one or more Global Navigational Satellite Systems (GNSS, e.g., GPS or GLONASS), one or more mobile television broadcast standards (e.g., ATSC-M / H or DVB-H), and / or any other wireless communication protocols, if desired. Other combinations of wireless communication standards (including three or more wireless communication standards) are also possible.

[0044] As shown, some user devices may be able to communicate directly with each other, i.e., without intermediate infrastructure devices such as base station 102A or RSU 110A. As shown, vehicle 106A may conduct V2X-related communications directly with vehicle 106B. Similarly, vehicle 106B may conduct V2X-related communications directly with PUE 104B. Such peer-to-peer communications may utilize a “sidelink” interface, such as a PC5 interface, for some LTE and / or 5G NR embodiments. In some embodiments, the PC5 interface supports direct cellular communications between user devices (e.g., between vehicles 106), and the Uu interface supports cellular communications with infrastructure devices such as base stations. The PC5 / Uu interface is used merely as an example, and PC5, as used herein, may represent various other possible wireless communication technologies that enable direct sidelink communications between user devices, and Uu may represent cellular communications between user devices and infrastructure devices such as base stations. Some user devices, such as the PUE 104A, in a V2X system may not be able to perform sidelink communications, for example because they lack certain hardware necessary to perform such communications.

[0045] As shown in the figure, the exemplary V2X system includes several infrastructure devices in addition to the user devices mentioned above. As used herein, "infrastructure devices" in the context of a V2X system refer to certain devices in a V2X system that are not user devices and are not carried by traffic actors (i.e., pedestrians, vehicles, or other mobile users), but that facilitate the participation of user devices in the V2X network. The infrastructure devices in the exemplary V2X system include a base station 102A and a roadside unit (RSU) 110A.

[0046] Base station (BS) 102A may be a base transceiver station (BTS) or cell site ("cellular base station") and may include hardware that enables wireless communication with user devices, such as user devices 104A and 106A.

[0047] A communication area (i.e., coverage area) of a base station may be referred to as a "cell" or "coverage." The base station 102A and user devices, such as the PUE 104A, may be configured to communicate over a transmission medium using any of a variety of radio access technologies (RATs), also referred to as wireless communication technologies or telecommunications standards, such as GSM, UMTS, LTE, LTE-Advanced (LTE-A), LTE-Vehicle (LTE-V), HSPA, 3GPP2 CDMA2000, 5G NR, etc. It should be noted that the base station 102A may alternatively be referred to as an "eNodeB" or eNB when implemented in the context of LTE, whereas the base station 102A may alternatively be referred to as a "gNodeB" or gNB when implemented in the context of 5G NR.

[0048] As shown in the figure, the base station 102A may also be equipped to communicate with the network 100 (e.g., the V2X network as well as a telecommunications network such as a cellular service provider's core network, a public switched telephone network (PSTN), and / or the Internet, among other possibilities). Thus, the base station 102A may facilitate communication between user devices and / or between the user devices and the network 100. In particular, the cellular base station 102A may provide various telecommunications functions, such as voice, SMS, and / or data services, to user devices, such as UE 104A. In particular, the base station 102A may provide connected user devices, such as UE 104A and vehicle 106A, with access to the V2X network.

[0049] Thus, the base station 102A may operate as a "serving cell" for the user devices 104A and 106A as shown in FIG. 1, but the user devices 104B and 106B may also be able to communicate with the base station 102A. The illustrated user devices, i.e., the user devices 104A, 104B, 106A, and 106B, may also be able to receive signals from (which may be within the communication range of) one or more other cells (which may be provided by the base stations 102B-102N and / or any other base stations), which may be referred to as "neighboring cells." Such cells may also facilitate communication between the user devices and / or between the user devices and the network 100. Such cells may include "macro" cells, "micro" cells, "pico" cells, and / or cells providing various other granularities of service area size. For example, the base stations 102A-102B shown in FIG. 1 may be macro cells, and the base station 102N may be a micro cell. Of course, other configurations are possible.

[0050] The Roadside Unit (RSU) 110A constitutes another infrastructure device that can be used to provide access to a V2X network to a particular user device. The RSU 110A can be one of various types of devices, such as a base station, e.g., a transceiver station (BTS) or cell site ("cellular base station"), or another type of device that includes hardware that enables wireless communication with user devices and facilitates their participation in the V2X network.

[0051] The RSU 110A may be configured to communicate using one or more wireless networking communication protocols (e.g., Wi-Fi), cellular communication protocols (e.g., LTE, LTE-V, 5G NR, etc.), and / or other wireless communication protocols. In some embodiments, the RSU 110A may be capable of communicating with devices using a “sidelink” technology such as PC5.

[0052] The RSU 110A can communicate directly with user devices, such as the illustrated vehicles 106A and 106B. The RSU 110A can also communicate with the base station 102A. In some cases, the RSU 110A can provide access to the base station 102A for a particular user device, for example the vehicle 106B. Although the RSU 110A is shown communicating with the vehicle 106, it may also be capable of communicating (or otherwise) with the PUE 104. Similarly, the RSU 110A may not necessarily forward user device communications to the base station 102A. In some embodiments, the RSU 110A can configure the base station itself and / or forward communications to the server 120.

[0053] The server 120 constitutes a network entity of the V2X system as shown in the figure and may be referred to as a cloud server. The base station 102A and / or the RSU 110A may relay some V2X-related communications between the user devices 104 and 106 and the server 120. The server 120 may be used to process certain information collected from multiple user devices and may manage V2X communications to the user devices to coordinate traffic activity. In various other embodiments of the V2X system, various functions of the cloud server 120 may be performed by an infrastructure device, such as the base station 102A or the RSU 110A, by one or more user devices, and / or not at all. Figure 2 - Communication between UE and base station

[0054] 2 illustrates a user equipment (UE) device 104 (e.g., one of the PUEs 104A or 104B of FIG. 1) in communication with a base station 102 (e.g., base station 102A of FIG. 1) according to some embodiments. The UE 104 may be a device with cellular communication capabilities, such as a mobile phone, a handheld device, a computer or tablet, or virtually any type of portable wireless device.

[0055] The UE 104 may include a processor configured to execute program instructions stored in a memory. The UE 104 may perform any of the method embodiment described herein by executing such stored instructions. Alternatively, or in addition, the UE 104 may include a programmable hardware element, such as a field programmable gate array (FPGA), configured to perform any of the method embodiment described herein, or any portion of any of the method embodiment described herein.

[0056] The UE 104 may include one or more antennas for communicating using one or more wireless communication protocols or technologies. In some embodiments, the UE 104 may be configured to communicate using, for example, CDMA2000 (1xRTT / 1xEV-DO / HRPD / eHRPD), LTE, and / or 5G NR using a single shared radio, and / or 5G NR or LTE using a single shared radio. The shared radio may be coupled to a single antenna or to multiple antennas (e.g., for MIMO) to perform wireless communication. In general, a radio may include any combination of a baseband processor, analog RF signal processing circuitry (e.g., including filters, mixers, oscillators, amplifiers, etc.), or digital processing circuitry (e.g., for digital modulation and other digital processing). Similarly, a radio may perform one or more receive and transmit chains using the hardware described above. For example, the UE 104 may share one or more portions of the receive and / or transmit chains between multiple wireless communication technologies, such as the technologies described above.

[0057] In some embodiments, the UE 104 may include a separate transmit and / or receive chain (e.g., including separate antennas and other radio components) for each wireless communication protocol over which the UE 104 is configured to communicate. As a further possibility, the UE 104 may include one or more radios shared among multiple wireless communication protocols and one or more radios used exclusively by a single wireless communication protocol. For example, the UE 104 may include a shared radio for communicating using either 5G NR, LTE, and / or 1xRTT (or alternatively, LTE or GSM), and separate radios for communicating using each of Wi-Fi and Bluetooth. Other configurations are possible. Figure 3 - UE block diagram

[0058] 3 illustrates an example block diagram of a UE 104, according to some embodiments. As shown, the UE 104 may include a system on chip (SOC) 300, which may include portions for various purposes. For example, as shown, the SOC 300 may include a processor(s) 302, which may execute program instructions for the UE 104, and a display circuit 304, which may perform graphics processing and provide display signals to a display 360. The processor(s) 302 may be coupled to a memory management unit (MMU) 340, which may be configured to receive addresses from the processor(s) 302 and translate those addresses to locations in memory (e.g., memory 306, read only memory (ROM) 350, NAND flash memory 310), and / or to other circuits or devices, such as the display circuit 304, wireless communication circuit 330, connector I / F 320, and / or display 360. The MMU 340 may be configured to perform memory protection and page table translation or setup. In some embodiments, the MMU 340 may be included as part of the processor(s) 302.

[0059] As shown, the SOC 300 may be coupled to various other circuits of the UE 104. For example, the UE 104 may include various types of memory (including, e.g., NAND flash memory 310), a connector interface 320 (e.g., for coupling to a computer system, a dock, a charging station, etc.), a display 360, and wireless communication circuitry 330 (e.g., for LTE, LTE-A, LTE-V, 5G NR, CDMA2000, Bluetooth, Wi-Fi, GPS, etc.). The UE may also include at least one SIM device, and may include two SIM devices, each providing an individual International Mobile Subscriber Identity (IMSI) and associated functions.

[0060] As shown, the UE device 104 may include at least one antenna (and possibly multiple antennas, e.g., for MIMO and / or to implement different wireless communication techniques, among other possibilities) for performing wireless communication with base stations, access points, and / or other devices. For example, the UE device 104 may perform wireless communication using antenna 335.

[0061] The UE 104 may also include and / or be configured for use with one or more user interface elements, which may include any of a variety of elements, such as a display 360 (which may be a touchscreen display), a keyboard (which may be a separate keyboard or may be implemented as part of the touchscreen display), a mouse, a microphone and / or a speaker, one or more cameras, one or more buttons, and / or any of a variety of other elements capable of providing information to a user and / or receiving or interpreting user input.

[0062] As described herein, the UE 104 may include hardware and software components for implementing functions for performing more efficient vehicle-related communications as described herein. The processor 302 of the UE device 104 may be configured to implement some or all of the methods described herein, for example, by executing program instructions stored in a memory medium (e.g., a non-transitory computer-readable memory medium). In other embodiments, the processor 302 may be configured as a programmable hardware element, such as a field programmable gate array (FPGA), or as an application specific integrated circuit (ASIC). Alternatively (or in addition), the processor 302 of the UE device 104 may be configured to perform some or all of the functions described herein in conjunction with one or more of the other components 300, 304, 306, 310, 320, 330, 335, 340, 350, 360. Figure 4 - Base Station Block Diagram

[0063] 4 illustrates an example block diagram of a base station 102 (e.g., base station 102A of FIG. 1) according to some embodiments. It should be noted that the base station of FIG. 4 is merely one example of a possible base station. As shown, the base station 102 may include a processor(s) 404 capable of executing program instructions for the base station 102. The processor(s) 404 may also be coupled to a memory management unit (MMU) 440, which may be configured to receive addresses from the processor(s) 404 and translate those addresses to locations in memory (e.g., memory 460 and read-only memory (ROM) 450) or other circuits or devices.

[0064] The base station 102 may include at least one network port 470. The network port 470 may be configured to couple to a telephone network and provide multiple devices, such as the UE device 104, access to the telephone network.

[0065] Network port 470 (or additional network ports) may also or alternatively be configured to couple to a cellular network, for example, a core network of a cellular service provider. The core network may provide mobility-related services and / or other services to multiple devices, such as UE device 104. In some cases, network port 470 may be coupled to a telephone network via the core network and / or the core network may provide telephone services (e.g., among other UE devices serviced by the cellular service provider).

[0066] In some embodiments, the base station 102 may be a next generation base station, e.g., a 5G New Radio (5G NR) base station, or "gNB." In such embodiments, the base station 102 may be connected to a conventional evolved packet core (EPC) network and / or an NR core (NRC) network. In addition, the base station 102 may be considered a 5G NR cell and may include one or more transition and reception points (TRPs). In addition, a UE capable of operating according to 5G NR may be connected to one or more TRPs in one or more gNBs.

[0067] The base station 102 may include at least one antenna 434, and possibly multiple antennas. The at least one antenna 434 may be configured to operate as a wireless transceiver and may be further configured to communicate with the UE device 104 via the radio 430. The antenna 434 communicates with the radio 430 via a communication chain 432. The communication chain 432 may be a receive chain, a transmit chain, or both. The radio 430 may be configured to communicate according to various wireless communication standards, including, but not limited to, LTE, LTE-A, LTE-V, GSM, UMTS, CDMA2000, 5G NR, Wi-Fi, etc.

[0068] The base station 102 may be configured to communicate wirelessly using multiple wireless communication standards. In some cases, the base station 102 may include multiple radios that may enable the base station 102 to communicate according to multiple wireless communication technologies. For example, as one possibility, the base station 102 may include an LTE radio for performing communications according to LTE, as well as a 5G NR radio for performing communications according to 5G NR. In such a case, the base station 102 may be capable of operating as both an LTE base station and a 5G NR base station. As another example, the base station 102 may include a 5G NR radio for performing communications according to 5G NR, as well as a Wi-Fi radio for communicating according to Wi-Fi. In such a case, the base station 102 may operate as both a 5G NR base station and a Wi-Fi access point. As a further possibility, the base station 102 may include a multi-mode radio that may enable communication according to any of multiple wireless communication technologies (e.g., LTE and Wi-Fi, LTE and UMTS, LTE and CDMA2000, UMTS and GSM, etc.).

[0069] As described further herein below, the BS 102 may include hardware and software components for performing or supporting the execution of the features described herein. The processor 404 of the base station 102 may be configured to perform or support the execution of some or all of the methods described herein, for example, by executing program instructions stored in a memory medium (e.g., a non-transitory computer-readable memory medium). Alternatively, the processor 404 may be configured as a programmable hardware element, such as a field programmable gate array (FPGA), or as an application specific integrated circuit (ASIC), or as a combination thereof. Alternatively (or in addition), the processor 404 of the BS 102, together with one or more of the other components 430, 432, 434, 440, 450, 460, 470, may be configured to perform or support the execution of some or all of the features described herein. Figure 5 - Sidelink Resource Management

[0070] As mentioned above, certain user devices (or UE devices) may be able to communicate with each other directly, i.e., without intermediate infrastructure devices such as the base station 102A or the RSU 110A. This direct communication between two wireless devices, such as between two vehicles or between a vehicle UE and a pedestrian UE, is called sidelink communication. In other words, two UE devices performing peer-to-peer (direct) communication with each other may each utilize a "sidelink" interface and are said to be communicating over a sidelink channel.

[0071] In some existing implementations, during sidelink communication, a listen-before-talk (LBT) mechanism may be used to access a shared medium (e.g., unlicensed bands commonly used for Wi-Fi, Bluetooth, and other short- to medium-range communications, e.g., non-3GGP access) to avoid collisions (e.g., transmissions emanating from two or more wireless devices attempting to access the shared medium) and improve medium utilization efficiency. However, the LBT mechanism is not collision-free. In other words, the LBT mechanism cannot guarantee collision-free transmissions.

[0072] For example, in the case of unicast transmission, the transmitter can easily detect a transmission collision based on the receiver's Acknowledgement / Negative Acknowledgement (ACK / NACK) feedback. However, in the case of multicast (or groupcast) transmission, the transmitter may not be able to easily detect a collision based on the receiver's ACK / NACK, at least in part because of the high traffic associated with the ACK / NACK from multiple receivers, and because the transmitter cannot distinguish (or separate) a transmission collision from a channel quality problem based on the received ACK / NACK. In other words, the receivers in a multicast transmission may have different locations with different channel qualities, so the reason for the NACK (e.g., a transmission collision for poor channel quality) cannot be determined by the transmitter. In addition, in the case of broadcast transmission, it is known that feedback from the receiver is not feasible, and thus, in this scenario, the transmitter will have no knowledge of the collision. Furthermore, in some implementations, the transmitter can reserve periodic slots within the reservation period for communication. In such an embodiment, if a collision occurs, it may persist for at least a portion of the reservation period (and in the worst case scenario, for the duration of the reservation period) if the transmitter does not (or cannot) detect the collision.

[0073] As an example, vehicle-to-everything (V2X) communications, such as those specified by 3GPP TS 22.185 V14.3.0, enable communications between a vehicle (e.g., a mobile unit in the vehicle, such as a wireless device configured or currently contained in the vehicle, and / or another transmitter that is included or configured in the vehicle) and various wireless devices. For example, as shown in FIG. 5, a vehicle, such as vehicle 502a, may communicate with various devices (e.g., devices 502b-f), such as roadside units (RSUs), infrastructure (V2I), networks (V2N), pedestrians (V2P), and / or other vehicles (V2V). Additionally, as shown, various devices in a V2X framework may communicate with other devices. V2X communications may utilize both long-range (e.g., cellular) communications as well as short- to medium-range (e.g., non-cellular) communications. In some contemplated implementations, non-cellular communications may use unlicensed bands as well as dedicated spectrum in 5.9 GHz. Furthermore, V2X communication may include unicast, multicast, groupcast, and / or broadcast communication. Each communication type may use the LBT mechanism. Furthermore, under the V2X communication protocol, a transmitter may reserve periodic slots within a reservation period. Thus, as described above, in various cases, a transmitter utilizing V2X communication may not be able to detect collisions after using the LBT mechanism in some cases.

[0074] To aid in collision prevention on a shared sidelink channel, various UEs in a network (e.g., a V2X network) may perform sidelink resource management, both for network-assisted and autonomous (e.g., non-network-assisted) resource management. In other words, various UE devices may operate to determine or schedule the use of sidelink resources for transmissions to other UEs. In some embodiments, a UE, such as the UE 106, may create a semi-persistent sidelink schedule for certain resources. The UE may periodically broadcast a resource occupation message (RO message). The RO message may include the (scheduled) resource blocks (RBs) and / or subframes to be used, the period of the resource occupation (e.g., reservation), and / or the remaining time of the resource occupation (e.g., reservation). Additionally, in some embodiments, a maximum allowed channel occupation time (T_max_COT) may be defined. In such embodiments, the initial remaining time of the resource occupation should not exceed the maximum allowed channel occupation time. In other words, the resource occupation may only be for a time that is shorter than the maximum allowed channel occupation time.

[0075] In some embodiments, when a UE enters a new system (e.g., a new set of UEs and / or a new location), the UE may listen to the channel to collect existing UE RO messages to determine available resources in the new system. In other words, before transmitting a RO message when entering a new set / area of ​​UEs (e.g., a set of UEs with proximity for sidelink communications), the UE may determine available resources via reception of RO messages from neighboring UEs. In some embodiments, once resource occupancy expires, the UE may determine available resources via reception of RO messages from neighboring UEs before transmitting a new RO message. User Equipment Power Saving via Sidelink Scheduling Requests and Resource Allocation

[0076] In some existing implementations, 5G NR V2X may include various scheduling modes. For example, 5G NR V2X Mode 2 may be designed for a UE to self-determine sidelink transmission resources. 5G NR V2X Mode 2 includes various sub-modes, including: Mode 2(a): A user equipment device (UE) autonomously selects sidelink resources for transmission. Mode 2(b): The UE assists in sidelink resource selection for other UEs. Mode 2(c): The UE is configured with an NR configured grant (e.g., a network-defined semi-persistent grant) for sidelink transmissions. Mode 2(d): The UE schedules other UEs for sidelink transmissions. In addition, existing implementations of V2X may support semi-persistent scheduling (SPS), e.g., configured grants, due to the periodicity of V2X messaging. For example, semi-persistent resources in SPS may represent resources repeated in time over a set of non-contiguous subframes with a certain repetition period. Semi-persistent resources may be scheduled over a set of non-contiguous subframes with a certain subframe repetition period. Furthermore, existing implementations of SPS (e.g., LTE V2X) and their corresponding resource allocation designs are optimized for broadcast services. However, 5G NR V2X Mode 2 further supports both unicast and groupcast services. Thus, there is a strong need to extend the method to support semi-persistent resource allocation for unicast and groupcast services in 5G NR V2X Mode 2.

[0077] In NR V2X R16, both Mode 1 and Mode 2 resource allocation schemes may be supported. The Mode 2 resource allocation scheme may involve the transmitting UE selecting sidelink transmission resources based on its own sensing and resource selection procedures. The Rel-17 sidelink enhancements aim to specify resource allocation by introducing the principles of Rel-14 LTE sidelink random resource selection and partial sensing into Rel-16 NR sidelink resource allocation Mode 2.

[0078] As mentioned above, when using Mode 2, some UEs may need to periodically perform sensing operations on relatively high frequency sidelink channels in order to identify and utilize potential resources of other UEs for sidelink communications. Such active sensing may consume a relatively high rate of device resources, e.g., power. However, even the option of reducing sensing to partial sensing (e.g., monitoring only a subset of subframes that the UE is receiving) still consumes energy. Furthermore, the option of not performing sensing (e.g., random resource selection) may increase the likelihood of resource collisions.

[0079] This potentially high resource usage and potentially high power consumption rate may place a heavy burden on certain devices participating in a V2X system. For infrastructure devices such as base stations and roadside units (RSUs), which may have large resource and power capabilities, e.g., not battery powered, this high resource usage may be less of a concern. Similarly, for certain vehicular devices, which may also have access to a wide range of power capabilities, this may be less of a concern. However, the potentially high power consumption associated with sensing the sidelink channel for available sidelink resources may overburden certain handheld or portable battery powered devices, i.e., certain user equipment (UE) devices, participating in a V2X network, along with other V2X communications. A UE in a V2X system may be a UE carried or worn by a pedestrian or other person, where the term pedestrian UE (PUE) includes a UE carried by a person who may be stationary, walking, running, cycling, etc., as explained above.

[0080] Therefore, improved power saving and communication techniques may be desirable in V2X systems involving UEs, especially PUEs, since UEs are generally resource limited (battery powered and therefore power limited), and this is especially true for wearable UEs, e.g., smart watches or smart glasses, which are more power constrained devices.

[0081] In some embodiments, a first UE, called "slave UE", may request a second UE, called "master UE", to offload the task of determining available sidelink resources. The request made by the first UE may be in the form of a scheduling request. In other words, the first UE may be power limited and therefore seek to reduce power consumption by offloading some communication or sensing responsibilities to the less power limited master UE. To offload this responsibility, the first UE transmits a sidelink scheduling request to the master UE. More specifically, the establishment of the sidelink scheduling request enables inter-UE coordination between the master UE and the slave UE, allowing the master UE to communicate and instruct the first UE regarding resource allocation and sensing protocols. An example of inter-UE coordination could be that a set of resources is determined by the master UE (UE-B). This set is then transmitted to the first UE (UE-A) (operating in mode 2), which then takes this received resource set into account in the resource selection for its own transmission. The effect of this inter-UE cooperation is intended to result in reduced power consumption and latency for the first UE, in addition to improved reliability due to shared or directed responsibility related to resource allocation and sensing.

[0082] In some embodiments, the slave UE may be power limited and therefore may attempt to connect to the master UE to receive scheduling information, i.e., to offload the task of determining the scheduling information. The master UE may have more available power than the slave UE and therefore may provide scheduling information to the slave UE to reduce the slave UE's power utilization. As an example, the master UE may not be power limited, e.g., the master UE may be a vehicular UE or an RSU. Alternatively, the master UE may also be power limited, but with less stringent power restrictions. For example, the slave UE may be a wearable device such as a smart watch, and the master UE may be a smartphone. Furthermore, the above master and slave relationship should not be limited to the above examples referring to the slave UE being a wearable device such as a smart watch and the master UE being a smartphone, or the slave UE being a smartphone and the master VUE. Furthermore, the connection between the slave UE and the master UE need not be one-to-one. In some aspects, multiple slave UEs may be connected to a single master UE, and in other embodiments, multiple master UEs may be connected to a single slave UE. Figure 6 - Slave UE Data Transmission

[0083] FIG. 6 illustrates an example procedure for UE data transmission, according to some embodiments.

[0084] First, in step 602, a slave UE may transmit sidelink scheduling configuration information with the master UE to configure master / slave communication with the master UE. The sidelink scheduling configuration information may be included in the sidelink control information (SCI) and may detail, for example, resource block allocation, modulation and coding scheme, group destination ID (for sidelink communication), and ProSe Per-Packet Priority (PPPP, for V2X sidelink communication). Additionally, the configuration of a sidelink scheduling request (S-SR) may involve the need for a pair of UEs to configure certain S-SR resources, i.e. resources to be used for future transmissions of a scheduling request (offload request), which may consist of time resources, frequency resources, or coding information.

[0085] The S-SR resource configuration may also include information regarding the slot offset value to be configured, the period of S-SR, QoS, a specific PRB of S-SR, or a cyclic shift of the S-SR sequence. In addition, the configuration of S-SR between a pair of UEs may include the recommended resource size (e.g., the number of subchannels), the number of blind retransmissions, data QoS, MCS table, DMRS port, power control parameters (e.g., nominal power (P o,SL ) or SL path loss scaling factor (α SL Sidelink data transmission parameters such as

[0086] In step 604, the slave UE may enter a reduced sensing mode (i.e., sleep mode) and thus not perform full sensing as it normally does. In the case of partial sensing, the slave UE may monitor only a subset of the available subframes. The slave UE may enter a reduced power mode to reduce power consumption and extend battery life. As briefly discussed above, the slave UE may be power limited and therefore may attempt to reduce power consumption by offloading communication or sensing responsibilities to a master UE that is less power limited, as described further below.

[0087] The slave UE may then collect sidelink data (e.g., from the VUE, PUE, or other UEs) to be redirected to the master UE or other UEs, in step 606. This sidelink data may also include information related to different UEs in the network, such as motion information (e.g., speed, acceleration, and / or braking status), position or location information (e.g., latitude and longitude, altitude, etc.), and other details.

[0088] In step 608, the slave UE may send a sidelink scheduling request (S-SR) to the master UE to transmit this sidelink data. More specifically, the slave UE may send the sidelink scheduling request to offload the task of determining scheduling resources available to the slave UE to another device (e.g., the master device). Thus, the sidelink scheduling request (S-SR) may be referred to as an offload request, or more appropriately characterized as a "sidelink resource determination offload request."

[0089] As illustrated in Figure 7, in response to receiving the S-SR from the slave UE, the master UE may determine a set of sidelink transmission resources for use by the second UE on the sidelink channel. This set of sidelink transmission resources may be a set of time, frequency, and / or code corresponding to slots or physical resource blocks (PRBs). Using this determined resource information, the master UE can communicate to the slave UE which resources it has recommended and whether the resources are reserved or unreserved.

[0090] Furthermore, after the slave UE transmits an S-SR to the master UE, the slave UE may monitor the channel to receive recommended resources from the master UE. This monitoring window may be pre-configured, configured per resource pool, or configured by PC5-RRC. In addition, the size of the monitoring window may depend on the period of the S-SR, and in some embodiments, the monitoring window may be equal to the period of the S-SR. Furthermore, if the slave UE does not receive a transmission from the master UE for the recommended resources after the monitoring window, the slave UE may transmit another S-SR.

[0091] In step 610, the slave UE receives the recommended resources from the master UE. The recommended resources received by the slave UE are in response to the scheduling request sent in 608. The master UE may utilize the SCI stage 2 format to indicate the source ID and destination ID of the recommended resources, including the number of recommended resources, the time interval between the current slot and the first recommended slot, and the sub-channel index and sub-channel number of the first recommended slot. The slave UE may use this information to more effectively communicate with the master UE or other UEs regarding the sidelink data it is about to transmit to the master UE or other UEs. Furthermore, the master UE's recommendation may take into account in advance the possibility of transmission / reception symbol collisions and the recommended resources to avoid such collisions. This makes the communication between the master UE and the slave UE more efficient. Importantly, the slave UE may receive and use these recommended resources without having to expend its own power or resources in detecting / determining these available resources.

[0092] Further selection among the recommended resources is also possible. For example, the slave UE may directly use all of the resources recommended by the master UE. In another aspect, the master UE may recommend N resource units and the slave UE may randomly select M resource units, where M is less than or equal to N. Furthermore, in another aspect, the slave UE may select M resource units from the N recommended resources based on full or partial sensing. Additionally, in another aspect, the slave UE may not measure the sidelink channel during the monitoring window. In this example, if the slave UE receives a transmission from the master UE regarding the recommended resources during the monitoring window, the slave UE may send subsequent sidelink data using the recommended resources from the master UE.

[0093] Finally, in step 612, the slave UE transmits the sidelink data to the master UE based on or using the recommended resources. As explained above, the sidelink data may also include information related to different UEs in the network, such as motion information (e.g., speed, acceleration, and / or braking status), position or location information (e.g., latitude and longitude, altitude, etc.), and other details.

[0094] Figure 7 - Master UE data transmission

[0095] 7 illustrates an example procedure for master UE data transmission according to some embodiments. More specifically, FIG. 7 illustrates the operation of the master UE in response to receiving a scheduling request from a first UE, i.e., in response to the scheduling request (offload request) transmitted at 608.

[0096] First, in step 702, the master UE may configure a sidelink scheduling request with the slave UE to establish master / slave communication with the slave UE as described above in 602. Thus, the master UE operations in 702 relate to the configuration of S-SR resources and are performed in conjunction with the slave UE operations in 602.

[0097] In addition, the configuration of S-SR between a pair of UEs includes the recommended resource size (e.g., the number of subchannels), the number of blind retransmissions, data QoS, MCS table, DMRS port, and power control parameters (e.g., nominal power (P o,SL ) or SL path loss scaling factor (α SL )) may also be included.

[0098] As described herein, a slave UE may be power limited and therefore attempt to reduce power consumption by offloading communication or sensing responsibilities to a less power limited master UE. More specifically, the establishment of resources for sidelink scheduling requests enables inter-UE coordination between the master UE and the slave UE to communicate and provide instructions regarding resource allocation and sensing protocols. More specifically, the establishment of resources for sidelink scheduling requests enables a first UE (slave UE) to request the master UE to perform sidelink resource decisions on its behalf.

[0099] Next, in step 704, the master UE may perform sensing (or partial sensing) to detect and identify nearby UEs and their respective available or unavailable resources. In the case of partial sensing, the UE may monitor only a subset of subframes. By performing sensing tasks normally associated with the slave UE, the master UE may offload the sensing responsibilities of the slave UE. This may not only allow the slave UE to save power more efficiently, but may also result in other improvements in terms of enhanced communication reliability and reduced latency. In particular, since the master UE is less power constrained (or less power constrained) than the first UE, the master UE may be able to perform more comprehensive sensing, and thus may be able to generate a more reliable set of available (candidate) resources than can be generated by the first UE.

[0100] In step 706, the master UE receives a sidelink scheduling request from the slave UE, which may be coordinated with an attempt to schedule and receive sidelink data from the slave UE. In response to receiving the S-SR from the slave UE, the master UE may determine, e.g. based on the detection performed in 704, a set of sidelink transmission resources for use by the second UE on the sidelink channel. This set of sidelink transmission resources may be a set of time, frequency and code corresponding to slots or physical resource blocks (PRBs).

[0101] In step 708, the master UE transmits information regarding the determined set of sidelink transmission resources to the slave UE. In other words, the master UE transmits the recommended resources to the slave UE. The master UE may provide the determined resource information to the slave UE for receiving the desired sidelink communication or data back. Furthermore, the master UE may utilize the SCI stage 2 format to indicate the source ID and destination ID of one or more of the multiple recommended resources, including the number of recommended resources, the time interval between the current slot and the first recommended slot, and the subchannel index and subchannel number of the first recommended slot. For example, if there is specific or prioritized information that the master UE would like to receive, the master UE may indicate certain preferred or recommended resources to the slave UE for the slave UE to utilize. In some aspects, the master UE may transmit a sidelink scheduling request to the slave UE to instruct the slave UE to return to a non-power saving mode, i.e., to "wake up", in which it may resume more full or partial sensing operations. In other embodiments, the determined set of sidelink transmission resources may be recommended resources rather than reserved resources. Alternatively, the determined set of sidelink transmission resources provided by the master UE to the slave UE may be both recommended and reserved resources.

[0102] As briefly described above with respect to Fig. 6, after the master UE receives the S-SR from the slave UE, the master UE may recommend resources to the slave UE. The PDB (packet delay budget) of this transmission may be pre-configured per resource pool or configured by PC5-RRC, and a resource selection window may be determined based on the PDB of this transmission. In addition, the data priority of this transmission may depend on the data priority level indicated by the S-SR, or may be pre-configured per resource pool or configured by PC5-RRC (similar to the PDB).

[0103] Furthermore, the recommended resources provided by the master UE may enable the slave UE to perform further selection among the recommended resources. For example, the master UE may recommend a certain number of resources N, among which the slave UE may directly use all resources recommended by the master. Alternatively, the slave UE may randomly select M resource units, where M is less than or equal to N, or the slave UE may select M resource units from the N recommended resources based on full or partial sensing. Furthermore, once the master UE sends a transmission about the recommended resources to the slave UE within the monitoring window, the slave UE may transmit subsequent sidelink data using the recommended resources from the master UE.

[0104] Finally, in step 710, the master UE receives sidelink data on the recommended resources from the slave UE. As explained above, this received sidelink data may include various data, such as motion or navigation information of the slave UE (e.g., speed, acceleration, and / or braking status), position or location information of the slave UE (e.g., latitude and longitude, altitude, etc.), and other details. Figure 8 – Sidelink Scheduling Request signal structure

[0105] FIG. 8 illustrates an example structure of a sidelink scheduling request (S-SR) signal, according to some embodiments. In particular, FIG. 8 illustrates the resources and structure of an S-SR signal system design, i.e., how the S-SR signal can be incorporated into other signaling, such as the PSFCH (Physical Sidelink Feedback Channel). With respect to the S_SR resources, the last symbols of a slot at a certain frequency may not be reserved for the PSFCH and therefore may be reused for use in transmitting the S_SR signal. These symbols may be frequency division multiplexed (FDM) with the PSFCH resources and may have the same or different periodicity as the other PSFCH resources. Furthermore, the transmission and reception of the S-SR may consume less power than the transmission and reception of the PSCCH or PSSCH signals.

[0106] In terms of structure, each S-SR signal may occupy one PRB and two symbols (similar to PSFCH). In addition, the sequence (with cyclic shift) may be based on a selection (similar to NR PUCCH format 0). Furthermore, the S-SR signal cyclic shift may be based on code domain multiplexing. In some embodiments, the S-SR resource configuration may be coded as a cyclic shift of the S-SR corresponding to an ACK-only sequence (i.e., a single sequence with a preconfigured cyclic shift). In this example, transmission of the sequence may indicate a positive sidelink SR, and absence or lack of sequence transmission may indicate a negative sidelink SR. According to other aspects, the S-SR resource configuration may be coded as a pair of cyclic shifts of the S-SR for an ACK / NACK sequence (i.e., two sequences with a pair of preconfigured cyclic shifts). In this example, transmission of a sequence with one cyclic shift may indicate a positive sidelink SR, and transmission of a sequence with the other cyclic shift may indicate a negative sidelink SR.

[0107] Further with regard to the structure, the S-SR resource configuration may be coded as a configuration index that indicates a certain sequence of S-SR. In this example, multiple sequences may be configured with multiple cyclic shifts, and each sequence may be associated with a configuration index. Furthermore, the S-SR sequence or sequence pair may be associated with a configuration corresponding to a sidelink data transmission parameter. Furthermore, each configuration index may correspond to a sidelink data transmission parameter such as a resource period, a number of subchannels, and / or a number of resources. In other aspects, each configuration index may correspond to a certain data QoS or a different cast type. In some embodiments, a combination of sequences indicated by a configuration index and sequences with pre-configured cyclic shift pairs (i.e., ACK / NACK sequences) may also be supported by the S-SR structure. Figure 9 - Frequency and code resources for sidelink scheduling request signal

[0108] FIG. 9 illustrates frequency and code resources for a sidelink scheduling request (S-SR) signal, according to some embodiments. More specifically, FIG. 9 illustrates that the frequency and code resources for S-SR depend on the ID of the scheduled UE (i.e., destination ID) and / or the ID of the scheduling UE (i.e., source ID). Furthermore, when determining S-SR resources, the first step may be to combine the source ID and destination ID. In some aspects, this may involve concatenating the destination ID and source ID. In other aspects, this may involve concatenating the source ID and destination ID. In some aspects, the first step when determining S-SR resources may involve combining the source ID and destination ID through the use of an exclusive-or (XOR) operation.

[0109] A second step in determining the S-SR resources may include calculating the total number of S-SR resources in the frequency and code domain. In some embodiments, this may involve indexing first by frequency and second by code. In other aspects, this may involve indexing first by code and second by frequency.

[0110] The frequency-code domain S-SR resource ID may then be determined by performing a modulo operation on the combination ID obtained from the first step above with the total number of frequency-code domain S-SR resources.

[0111] Finally, the UE may then transmit or receive an S-SR on the determined S-SR resource ID. Figure 10 - Master UE recommends unreserved resources

[0112] Figure 10 illustrates an example of how the master UE provides recommended but unreserved resources to the slave UE according to some embodiments. For example, after the master UE receives an S-SR from the slave UE, the master UE may then send signaling to indicate the recommended resources based on the sensing operation of the master UE. In addition, to avoid half-duplex issues of PSSCH reception and transmission, the master UE may send signaling to indicate the recommended resources based on the existing scheduling of the master UE. Furthermore, the recommended resources sent by the master UE may be encoded and delivered as PSSCH data.

[0113] For example, as shown in Figure 10, the first resource box (top left) may contain PSCCH data, as indicated by the arrow on the left. This PSCCH data may contain resource reservation information that is used to indicate resources for only the first resource box, and is not used to indicate the other two resource boxes.

[0114] Meanwhile, the SCI stage 2 for the PSSCH box may include resource recommendation information used to indicate the other two resource boxes (center and right). The two arrows on the right side of Fig. 10 indicate the resource recommendation information included in the SCI stage 2 for the PSSCH box. In other words, the two arrows on the right side may correspond to the master UE indicating recommended but unreserved resources via the SCI stage 2 of the PSSCH. Since these recommended resources are unreserved (in the PSCCH), other UEs may attempt to use these resources.

[0115] In another aspect, the recommended resources sent by the master UE may be delivered in the SCI stage 2 format. Furthermore, the SCI stage 2 format may be used to indicate the source ID and destination ID of the recommended resources. Furthermore, up to three separate resources may be indicated in the SCI stage 2 format, including the number of recommended resources, the time interval between the current slot and the first recommended slot, and the subchannel index and subchannel number of the first recommended slot. Furthermore, if the SCI stage 2 format indicates more than one recommended resource, the remaining resources are indicated as FRIV (frequency resource indicator value) and TRIV (time resource indicator value).

[0116] Additionally, other sidelink data transmission parameters can be indicated in SCI stage 2 to mitigate the slave UE's activity. For example, modulation and coding scheme (MCS), MCS table, DMRS port, along with HARQ feedback, may be always enabled in SCI stage 2 for this type. Additionally, CBR related information such as channel busy radio (CBR) level, and power control information (e.g. sidelink path loss PL SL , sidelink path loss scaling factor α SL ) may be indicated or the power level may be transmitted directly. Figure 11 - Master UE recommends reserved resources

[0117] FIG. 11 illustrates an example of how the master UE provides the slave UE with recommended and reserved resources in addition to the transfer of ownership of the reserved resources, according to some embodiments. For example, after the master UE receives an S-SR from the slave UE, the master UE may then send signaling to indicate recommended resources based on the master UE's sensing operation. These recommended resources may be reserved resources. In some embodiments, the resource reservation information may only be included in the PSCCH data. In this example, another UE receives the PSCCH to know which resources are reserved.

[0118] Furthermore, the master UE may indicate one or more reserved resources for the slave UE's transmission using the SCI stage 1, as shown in step 1102. Furthermore, the QoS may be transmitted as the configured sidelink data QoS and additional bits indicating the owner of the reserved resources may also be exchanged between the master UE and the slave UE.

[0119] To transfer ownership of the reserved resources, after receiving the HARQ-ACK in step 1104, the master UE may determine that the reserved resources used by the slave UE are the reserved resources at which the master UE can receive data. The master UE may then transfer the remaining reserved resources to the slave UE (i.e., transfer of ownership), as shown in step 1106. In doing so, the slave UE may then transmit appropriate sidelink data using the newly transferred reserved resources. On the other hand, if a HARQ-NACK is received, the master UE may determine that the reserved resources are not used by the slave UE. In this case, the master UE may send another transmission to the slave UE containing information that may include more recommended and reserved resources. In other words, the master UE may send an additional transmission containing information (more new resources may be reserved) to the slave UE using the next reserved resources, as shown in step 1108.

[0120] The embodiments of the present disclosure may be implemented in any of a variety of forms. For example, some embodiments may be implemented as a computer-implemented method, a computer-readable memory medium, or a computer system. Other embodiments may be implemented using one or more custom-designed hardware devices, such as an ASIC. Still other embodiments may be implemented using one or more programmable hardware elements, such as an FPGA.

[0121] In some embodiments, a non-transitory computer readable memory medium may be configured to store program instructions and / or data that, when executed by a computer system, cause the computer system to perform a method, such as any of the method embodiment embodiments described herein, or any combination of the method embodiment embodiments described herein, or any subset of any of the method embodiment embodiments described herein, or any combination of such subsets.

[0122] In some embodiments, a device (e.g., UE 104) may be configured to include a processor (or set of processors) and a memory medium, where the memory medium stores program instructions and the processor is configured to read and execute the program instructions from the memory medium, and the program instructions are executable to perform any of the various method embodiments described herein (or any combination of the method embodiments described herein, or any subset of any of the method embodiments described herein, or any combination of such subsets). The device may be implemented in any of a variety of forms.

[0123] Although the above embodiments have been described in considerable detail, numerous variations and modifications will become apparent to those skilled in the art once the above disclosure is fully appreciated, and it is intended that the following claims be interpreted to embrace all such variations and modifications.

Claims

1. by a first user equipment (UE), transmitting to a second UE a scheduling request configured to cause the second UE to determine a set of sidelink transmission resources for use by the first UE; receiving, from the second UE, information regarding a determined set of sidelink transmission resources, the determined set of sidelink transmission resources being determined based on the transmitted scheduling request, wherein the determined set of sidelink transmission resources are recommended, non-reserved resources; and transmitting sidelink communication to the second UE using at least a subset of the determined set of sidelink transmission resources; and A method comprising:

2. transmitting configuration information to the second UE, the configuration information specifying transmission resources to be used for transmitting the scheduling request; The method of claim 1 further comprising:

3. encoding said scheduling request as a cyclic shift of an S-SR corresponding to an ACK-only sequence; The method of claim 2 further comprising:

4. encoding the scheduling request as a cyclic shifted pair of S-SR corresponding to an ACK / NACK sequence; The method of claim 2 further comprising:

5. encoding the scheduling request as a configuration index that indicates a sequence of S-SRs, each sequence of S-SRs being associated with a configuration; The method of claim 2.

6. monitoring a wireless channel for arrival of the determined set of sidelink transmission resources; The method of claim 1 further comprising:

7. by a first user equipment (UE), receiving a scheduling request from a second UE, the scheduling request being configured to cause the first UE to determine a set of sidelink transmission resources for use by the second UE on a sidelink channel; determining a set of sidelink transmission resources for use by the second UE in response to the received scheduling request, wherein the determined set of sidelink transmission resources are recommended, non-reserved resources; and transmitting to the second UE information on the determined set of sidelink transmission resources usable by the second UE when transmitting on the sidelink channel; A method comprising:

8. determining the set of sidelink transmission resources by detecting communication traffic on the sidelink channel; The method of claim 7 further comprising:

9. determining the set of sidelink transmission resources based on an existing resource schedule maintained by the UE; The method of claim 7 further comprising:

10. An apparatus comprising at least one processor configured to cause a user equipment (UE) to perform the method of any one of claims 1 to 9.

11. a radio operably coupled to the at least one processor.

11. The apparatus of claim 10.

12. 10. A computer program comprising instructions executable by one or more baseband processors of a user equipment (UE) to cause the UE to perform a method according to any one of claims 1 to 9.

Images