Patent Description:
Wireless communication systems are rapidly growing in usage. One proposed use of wireless communications is in vehicular applications, particularly in V2X (vehicle-to-everything) systems. V2X systems allow for communication between vehicles (e.g., via communications devices housed in or otherwise carried by vehicles), pedestrian UEs (including UEs carried by other persons such as cyclists, and so forth), and other wireless communications devices for various purposes, such as to coordinate traffic activity, facilitate autonomous driving, and perform collision avoidance.

The increased communication requirements of certain V2X systems may strain the power and resource capabilities of portable, battery-powered UE devices. In addition, some UEs are more power limited than others and communicating with a host of UEs may present decreased battery life, increased latency, and degraded communication issues. Accordingly, improvements in the field would be desirable. The <NPL> discusses power saving and enhanced reliability and reduced latency for NR sidelink enhancements. <CIT> discusses systems and methods for unified channel access for broadcast, groupcast, and unicast communication in NR V2X sidelink communication. <CIT> discusses a data transmission method that reduces interference in multi-mode collaborative transmission.

Embodiments relate to wireless communications, including apparatuses, systems, and methods for utilization of an inter-UE coordination message, e.g., for V2X Mode <NUM> resource allocation.

The techniques described herein may be implemented in and/or used with a number of different types of devices, including but not limited to unmanned aerial vehicles (UAVs), unmanned aerial controllers (UACs), a UTM server, base stations, access points, cellular phones, tablet computers, wearable computing devices, portable media players, and any of various other computing devices.

While the features described herein may be susceptible to various modifications and alternative forms, specific embodiments thereof are 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 thereto are not intended to be limiting to the particular form disclosed, but on the contrary, the intention is to cover all modifications and alternatives falling within the scope of the subject matter as defined by the appended claims.

Various components may be described as "configured to" perform a task or tasks.

<FIG> illustrates an example vehicle-to-everything (V2X) communication system, according to some embodiments.

Vehicle-to-everything (V2X) communication systems may be characterized as networks in which vehicles, UEs, and/or other devices and network entities exchange communications in order to coordinate traffic activity, among other possible purposes. V2X communications include communications conveyed between a vehicle (e.g., a wireless device or communication device constituting part of the vehicle, or contained in or otherwise carried along by the vehicle, including a UE) 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 participating in a V2X network for the purpose of sharing V2X-related information.

V2X communications may, for example, adhere to 3GPP Cellular V2X (C-V2X) specifications, or to one or more other or subsequent standards whereby vehicles and other devices and network entities may communicate. V2X communications may utilize both long-range (e.g., cellular) communications as well as short- to medium-range (e.g., non-cellular) communications. Cellular-capable V2X communications may be called Cellular V2X (C-V2X) communications. C-V2X systems may use various cellular radio access technologies (RATs), such as <NUM> LTE or <NUM> NR RATs. Certain LTE standards usable in V2X systems may be called LTE-Vehicle (LTE-V) standards.

As shown, the example V2X system includes a number of user devices. As used herein, in the context of V2X systems, and as defined above, the term "user devices" may refer generally to devices that are associated with mobile actors or traffic participants in the V2X system, e.g., mobile (able-to-move) communication devices such as vehicles and pedestrian user equipment (PUE) devices. User devices in the example V2X system include the PUEs 103A and 103B and the vehicles 105A and 105B. Note that in various embodiments, the PUEs 103A and 103B and/or the vehicles 105A and 105B may each be a UE <NUM>, e.g., as further described herein.

The vehicles <NUM> may constitute various types of vehicles. For example, the vehicle 105A may be a road vehicle or automobile, a mass transit vehicle, or another type of vehicle. The vehicles <NUM> may conduct wireless communications by various means. For example, the vehicle 105A may include communications equipment as part of the vehicle or housed in the vehicle, or may communicate through a wireless communications device currently contained within or otherwise carried along 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 on board the vehicle, among other possibilities. For simplicity, the term "vehicle" as used herein may include the wireless communications equipment which represents the vehicle and conducts its communications. Thus, for example, when the vehicle 105A is said to conduct wireless communications, it is understood that, more specifically, certain wireless communications equipment associated with and carried along by the vehicle 105A is performing the wireless communications.

The pedestrian UEs (PUEs) <NUM> may constitute various types of user equipment (UE) devices, e.g., portable devices capable of wireless communication, such as smartphones, smartwatches, and so forth, and may be associated with various types of users. Thus, the PUEs <NUM> are UEs, e.g., such as UE <NUM>, and may be referred to as UEs and/or UE devices. Note that although referred to as PUEs (pedestrian UEs), the PUEs <NUM> may not necessarily be carried by persons who are actively walking near roads or streets. PUEs may refer to UEs participating in a V2X system that are carried by stationary persons, by persons walking or running, or by persons on vehicles that may not substantially bolster the devices' power capabilities, such as bicycles, scooters, or certain motor vehicles. Note also that not all UEs participating in a V2X system are necessarily PUEs.

The user devices may be capable of communicating using multiple wireless communication standards. For example, the PUE 103A may be configured to communicate using a wireless networking (e.g., Wi-Fi) and/or peer-to-peer wireless communication protocol (e.g., Bluetooth, Wi-Fi peer-to-peer, and so forth) in addition to at least one cellular communication protocol (e.g., GSM, UMTS, LTE, LTE-A, LTE-V, HSPA, 3GPP2 CDMA2000, <NUM> NR, and so forth). The PUE 103A may also and/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 broadcasting standards (e.g., ATSC-M/H or DVB-H), and/or any other wireless communication protocol, as desired. Other combinations of wireless communication standards (including more than two wireless communication standards) are also possible.

As shown, certain user devices may be able to conduct communications with one another directly, e.g., without an intermediary infrastructure device such as base station 102A or RSU 110A. As shown, vehicle 105A may conduct V2X-related communications directly with vehicle 105B. Similarly, the vehicle 105B may conduct V2X-related communications directly with PUE 103B. Such peer-to-peer communications may utilize a "sidelink" interface such as the PC5 interface in the case of some LTE and/or <NUM> NR embodiments. In some embodiments, the PC5 interface supports direct cellular communication between user devices (e.g., between vehicles <NUM>), while the Uu interface supports cellular communications with infrastructure devices such as base stations. The PC5/Uu interfaces are used only as an example, and PC5 as used herein may represent various other possible wireless communications technologies that allow for direct sidelink communications between user devices, while Uu in turn may represent cellular communications conducted between user devices and infrastructure devices, such as base stations. Some user devices in a V2X system, e.g., PUE 103A, may be unable to perform sidelink communications, e.g., because they lack certain hardware necessary to perform such communications.

As shown, the example V2X system includes a number of infrastructure devices in addition to the above-mentioned user devices. As used herein, "infrastructure devices" in the context of V2X systems refers to certain devices in a V2X system which are not user devices and are not carried by traffic actors (e.g., pedestrians, vehicles, or other mobile users), but rather which facilitate user devices' participation in the V2X network. The infrastructure devices in the example V2X system include base station 102A and roadside unit (RSU) 110A.

The base station (BS) 102A may be a base transceiver station (BTS) or cell site (a "cellular base station"), and may include hardware that enables wireless communication with user devices, e.g., with the user devices 103A and 105A.

The communication area (or coverage area) of the base station may be referred to as a "cell" or "coverage". The base station 102A and user devices such as PUE 103A may be configured to communicate over the transmission medium using any of various radio access technologies (RATs), also referred to as wireless communication technologies, or telecommunication standards, such as GSM, UMTS, LTE, LTE-Advanced (LTE-A), LTE-Vehicle (LTE-V), HSPA, 3GPP2 CDMA2000, <NUM> NR, and so forth. Note that if the base station 102A is implemented in the context of LTE, it may alternately be referred to as an 'eNodeB', or eNB whereas if the base station 102A is implemented in the context of <NUM> NR, it may alternately be referred to as a 'gNodeB', or gNB.

As shown, the base station 102A may also be equipped to communicate with a network <NUM> (e.g., the V2X network, as well as a core network of a cellular service provider, a telecommunication network such as a public switched telephone network (PSTN), and/or the Internet, among various possibilities). Thus, the base station 102A may facilitate communication between user devices and/or between user devices and the network <NUM>. The base station 102A may provide user devices, such as PUE 103A, with various telecommunication capabilities, such as voice, SMS and/or data services. In particular, the base station 102A may provide connected user devices, such as PUE 103A and vehicle 105A, with access to the V2X network.

Thus, while the base station 102A may act as a "serving cell" for user devices 103A and 105A as illustrated in <FIG>, the user devices 103B and 105B may also be capable of communicating with the base station 102A. The user devices shown, e.g., user devices 103A, 103B, 105A, and 105B may also be capable of receiving signals from (and may possibly be within communication range of) one or more other cells (which might be provided by base stations 102B-N and/or any other base stations), which may be referred to as "neighboring cells". Other configurations are of course also possible.

Roadside unit (RSU) 110A constitutes another infrastructure device usable for providing certain user devices with access to the V2X network. RSU 110A may be one of various types of devices, such as a base station, e.g., a transceiver station (BTS) or cell site (a "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.

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, <NUM> NR and so forth), and/or other wireless communication protocols. In some embodiments, RSU 110A may be able to communicate with devices using a "sidelink" technology such as PC5.

RSU 110A may communicate directly with user devices, such as the vehicles 106A and 106B as shown. RSU 110A may also communicate with the base station 102A. In some cases, RSU 110A may provide certain user devices, e.g., vehicle 106B, with access to the base station 102A. While RSU 110A is shown communicating with vehicles <NUM>, it may also (or otherwise) be able to communicate with PUEs <NUM>. Similarly, RSU 110A may not necessarily forward user device communications to the base station 102A. In some embodiments, the RSU 110A and may constitute a base station itself, and/or may forward communications to the server <NUM>.

The server <NUM> constitutes a network entity of the V2X system, as shown, and may be referred to as a cloud server. Base station 102A and/or RSU 110A may relay certain V2X-related communications between the user devices <NUM> and <NUM> and the server <NUM>. The server <NUM> may be used to process certain information collected from multiple user devices, and may administer V2X communications to the user devices in order to coordinate traffic activity. In various other embodiments of V2X systems, various functions of the cloud server <NUM> may be performed by an infrastructure device such as the base station 102A or RSU 110A, performed by one or more user devices, and/or not performed at all.

<FIG> illustrates a user equipment (UE) device <NUM> (e.g., one of the PUEs 103A or 103B and/or vehicles 105A or 105B in <FIG>) in communication with a base station <NUM> (e.g., the base station 102A in <FIG>), according to some embodiments. The UE <NUM> may be a device with cellular communication capability such as a mobile phone, a hand-held device, a computer or a tablet, or virtually any type of portable wireless device.

Alternatively, and/or in addition, the UE <NUM> may include a programmable hardware element such as an FPGA (field-programmable gate array) that is configured to perform any of the method embodiments described herein, or any portion of any of the method embodiments described herein.

The UE <NUM> may include one or more antennas for communicating using one or more wireless communication protocols or technologies. In some embodiments, the UE <NUM> may be configured to communicate using, for example, CDMA2000 (1xRTT / 1xEV-DO / HRPD / eHRPD) LTE, and/or <NUM> NR using a single shared radio and/or <NUM> NR or LTE using the single shared radio. The shared radio may couple to a single antenna, or may couple to multiple antennas (e.g., for MIMO) for performing wireless communications. 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 as well as other digital processing). Similarly, the radio may implement one or more receive and transmit chains using the aforementioned hardware. For example, the UE <NUM> may share one or more parts of a receive and/or transmit chain between multiple wireless communication technologies, such as those discussed above.

For example, the UE <NUM> might include a shared radio for communicating using any of <NUM> NR, LTE, and/or 1xRTT (or LTE or GSM), and separate radios for communicating using each of Wi-Fi and Bluetooth.

<FIG> illustrates an example simplified block diagram of a communication device <NUM>, according to some embodiments. It is noted that the block diagram of the communication device of <FIG> is only one example of a possible communication device. According to embodiments, communication device <NUM> may be a user equipment (UE) device (e.g., such as PUEs <NUM> and/or vehicles <NUM>), a mobile device or mobile station, a wireless device or wireless station, a desktop computer or computing device, a mobile computing device (e.g., a laptop, notebook, or portable computing device), a tablet, an unmanned aerial vehicle (UAV), a UAV controller (UAC) and/or a combination of devices, among other devices. As shown, the communication device <NUM> may include a set of components <NUM> configured to perform core functions. For example, this set of components may be implemented as a system on chip (SOC), which may include portions for various purposes. Alternatively, this set of components <NUM> may be implemented as separate components or groups of components for the various purposes. The set of components <NUM> may be coupled (e.g., communicatively; directly or indirectly) to various other circuits of the communication device <NUM>.

For example, the communication device <NUM> may include various types of memory (e.g., including NAND flash <NUM>), an input/output interface such as connector I/F <NUM> (e.g., for connecting to a computer system; dock; charging station; input devices, such as a microphone, camera, keyboard; output devices, such as speakers; and so forth), the display <NUM>, which may be integrated with or external to the communication device <NUM>, and cellular communication circuitry <NUM> such as for <NUM> NR, LTE, GSM, and so forth, and short to medium range wireless communication circuitry <NUM> (e.g., Bluetooth™ and WLAN circuitry).

Note that the term "SIM" or "SIM entity" is intended to include any of various types of SIM implementations or SIM functionality, such as the one or more UICC(s) cards <NUM>, one or more eUICCs, one or more eSIMs, either removable or embedded, and so forth. In some embodiments, the UE <NUM> may include at least two SIMs. Each SIM may execute one or more SIM applications and/or otherwise implement SIM functionality. Thus, each SIM may be a single smart card that may be embedded, e.g., may be soldered onto a circuit board in the UE <NUM>, or each SIM <NUM> may be implemented as a removable smart card. Thus, the SIM(s) may be one or more removable smart cards (such as UICC cards, which are sometimes referred to as "SIM cards"), and/or the SIMs <NUM> may be one or more embedded cards (such as embedded UICCs (eUICCs), which are sometimes referred to as "eSIMs" or "eSIM cards"). In some embodiments (such as when the SIM(s) include an eUICC), one or more of the SIM(s) may implement embedded SIM (eSIM) functionality; in such an embodiment, a single one of the SIM(s) may execute multiple SIM applications. Each of the SIMs may include components such as a processor and/or a memory; instructions for performing SIM/eSIM functionality may be stored in the memory and executed by the processor. In some embodiments, the UE <NUM> may include a combination of removable smart cards and fixed/non-removable smart cards (such as one or more eUICC cards that implement eSIM functionality), as desired. For example, the UE <NUM> may comprise two embedded SIMs, two removable SIMs, or a combination of one embedded SIMs and one removable SIMs. Various other SIM configurations are also contemplated.

As noted above, in some embodiments, the UE <NUM> may include two or more SIMs. The inclusion of two or more SIMs in the UE <NUM> may allow the UE <NUM> to support two different telephone numbers and may allow the UE <NUM> to communicate on corresponding two or more respective networks. For example, a first SIM may support a first RAT such as LTE, and a second SIM <NUM> support a second RAT such as <NUM> NR. Other implementations and RATs are of course possible. In some embodiments, when the UE <NUM> comprises two SIMs, the UE <NUM> may support Dual SIM Dual Active (DSDA) functionality. The DSDA functionality may allow the UE <NUM> to be simultaneously connected to two networks (and use two different RATs) at the same time, or to simultaneously maintain two connections supported by two different SIMs using the same or different RATs on the same or different networks. The DSDA functionality may also allow the UE <NUM> to simultaneously receive voice calls or data traffic on either phone number. In certain embodiments the voice call may be a packet switched communication. In other words, the voice call may be received using voice over LTE (VoLTE) technology and/or voice over NR (VoNR) technology. In some embodiments, the UE <NUM> may support Dual SIM Dual Standby (DSDS) functionality. The DSDS functionality may allow either of the two SIMs in the UE <NUM> to be on standby waiting for a voice call and/or data connection. In DSDS, when a call/data is established on one SIM, the other SIM is no longer active. In some embodiments, DSDx functionality (either DSDA or DSDS functionality) may be implemented with a single SIM (e.g., a eUICC) that executes multiple SIM applications for different carriers and/or RATs.

As shown, the SOC <NUM> may include processor(s) <NUM>, which may execute program instructions for the communication device <NUM> and display circuitry <NUM>, which may perform graphics processing and provide display signals to the display <NUM>. The processor(s) <NUM> may also be coupled to memory management unit (MMU) <NUM>, which may be configured to receive addresses from the processor(s) <NUM> and translate those addresses to locations in memory (e.g., memory <NUM>, read only memory (ROM) <NUM>, NAND flash memory <NUM>) and/or to other circuits or devices, such as the display circuitry <NUM>, short to medium range wireless communication circuitry <NUM>, cellular communication circuitry <NUM>, connector I/F <NUM>, and/or display <NUM>. The MMU <NUM> may be configured to perform memory protection and page table translation or set up. In some embodiments, the MMU <NUM> may be included as a portion of the processor(s) <NUM>.

As noted above, the communication device <NUM> may be configured to communicate using wireless and/or wired communication circuitry. The communication device <NUM> may be configured to perform methods for utilization of an inter-UE coordination message, e.g., for V2X Mode <NUM> resource allocation, as further described herein.

As described herein, the communication device <NUM> may include hardware and software components for implementing the above features for a communication device <NUM> to communicate a scheduling profile for power savings to a network. The processor <NUM> of the communication device <NUM> may be configured to implement part or all of the features described herein, e.g., by executing program instructions stored on a memory medium (e.g., a non-transitory computer-readable memory medium). Alternatively (or in addition), processor <NUM> may be configured as a programmable hardware element, such as an FPGA (Field Programmable Gate Array), or as an ASIC (Application Specific Integrated Circuit). Alternatively (or in addition) the processor <NUM> of the communication device <NUM>, in conjunction with one or more of the other components <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM> may be configured to implement part or all of the features described herein.

In addition, each integrated circuit may include circuitry (e.g., first circuitry, second circuitry, and so forth) configured to perform the functions of processor(s) <NUM>.

Further, as described herein, cellular communication circuitry <NUM> and short to medium range wireless communication circuitry <NUM> may each include one or more processing elements. In other words, one or more processing elements may be included in cellular communication circuitry <NUM> and, similarly, one or more processing elements may be included in short to medium range wireless communication circuitry <NUM>. Thus, cellular communication circuitry <NUM> may include one or more integrated circuits (ICs) that are configured to perform the functions of cellular communication circuitry <NUM>. In addition, each integrated circuit may include circuitry (e.g., first circuitry, second circuitry, and so forth) configured to perform the functions of cellular communication circuitry <NUM>. Similarly, the short to medium range wireless communication circuitry <NUM> may include one or more ICs that are configured to perform the functions of short to medium range wireless communication circuitry <NUM>. In addition, each integrated circuit may include circuitry (e.g., first circuitry, second circuitry, and so forth) configured to perform the functions of short to medium range wireless communication circuitry <NUM>.

<FIG> illustrates an example simplified block diagram of cellular communication circuitry, according to some embodiments. It is noted that the block diagram of the cellular communication circuitry of <FIG> is only one example of a possible cellular communication circuit. According to embodiments, cellular communication circuitry <NUM>, which may be cellular communication circuitry <NUM>, may be included in a communication device, such as communication device <NUM> described above. As noted above, communication device <NUM> may be a user equipment (UE) device, a mobile device or mobile station, a wireless device or wireless station, a desktop computer or computing device, a mobile computing device (e.g., a laptop, notebook, or portable computing device), a tablet and/or a combination of devices, among other devices.

The cellular communication circuitry <NUM> may couple (e.g., communicatively; directly or indirectly) to one or more antennas, such as antennas 435a-b and <NUM> as shown (in <FIG>). In some embodiments, cellular communication circuitry <NUM> may include dedicated receive chains (including and/or coupled to, e.g., communicatively; directly or indirectly. For example, as shown in <FIG>, cellular communication circuitry <NUM> may include a modem <NUM> and a modem <NUM>. Modem <NUM> may be configured for communications according to a first RAT, e.g., such as LTE or LTE-A, and modem <NUM> may be configured for communications according to a second RAT, e.g., such as <NUM> NR.

In some embodiments, the cellular communication circuitry <NUM> may be configured to perform methods utilization of an inter-UE coordination message, e.g., for V2X Mode <NUM> resource allocation, as further described herein.

As described herein, the modem <NUM> may include hardware and software components for implementing the above features or for time division multiplexing UL data for NSA NR operations, as well as the various other techniques described herein. The processors <NUM> may be configured to implement part or all of the features described herein, e.g., by executing program instructions stored on a memory medium (e.g., a non-transitory computer-readable memory medium). Alternatively (or in addition), processor <NUM> may be configured as a programmable hardware element, such as an FPGA (Field Programmable Gate Array), or as an ASIC (Application Specific Integrated Circuit). Alternatively (or in addition) the processor <NUM>, in conjunction with one or more of the other components <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM> and <NUM> may be configured to implement part or all of the features described herein.

In addition, each integrated circuit may include circuitry (e.g., first circuitry, second circuitry, and so forth) configured to perform the functions of processors <NUM>.

As described herein, the modem <NUM> may include hardware and software components for implementing the above features for communicating a scheduling profile for power savings to a network, as well as the various other techniques described herein. The processors <NUM> may be configured to implement part or all of the features described herein, e.g., by executing program instructions stored on a memory medium (e.g., a non-transitory computer-readable memory medium). Alternatively (or in addition), processor <NUM> may be configured as a programmable hardware element, such as an FPGA (Field Programmable Gate Array), or as an ASIC (Application Specific Integrated Circuit). Alternatively (or in addition) the processor <NUM>, in conjunction with one or more of the other components <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM> and <NUM> may be configured to implement part or all of the features described herein.

<FIG> illustrates an example of a baseband processor architecture for a UE (e.g., such as UE <NUM>), according to some embodiments. The baseband processor architecture <NUM> described in <FIG> may be implemented on one or more radios (e.g., radios <NUM> and/or <NUM> described above) or modems (e.g., modems <NUM> and/or <NUM>) as described above. As shown, the non-access stratum (NAS) <NUM> may include a <NUM> NAS <NUM> and a legacy NAS <NUM>. The legacy NAS <NUM> may include a communication connection with a legacy access stratum (AS) <NUM>. The <NUM> NAS <NUM> may include communication connections with both a <NUM> AS <NUM> and a non-3GPP AS <NUM> and Wi-Fi AS <NUM>. The <NUM> NAS <NUM> may include functional entities associated with both access stratums. Thus, the <NUM> NAS <NUM> may include multiple <NUM> MM entities <NUM> and <NUM> and <NUM> session management (SM) entities <NUM> and <NUM>. The legacy NAS <NUM> may include functional entities such as short message service (SMS) entity <NUM>, evolved packet system (EPS) session management (ESM) entity <NUM>, session management (SM) entity <NUM>, EPS mobility management (EMM) entity <NUM>, and mobility management (MM)/ GPRS mobility management (GMM) entity <NUM>. In addition, the legacy AS <NUM> may include functional entities such as LTE AS <NUM>, UMTS AS <NUM>, and/or GSM/GPRS AS <NUM>.

Thus, the baseband processor architecture <NUM> allows for a common <NUM>-NAS for both <NUM> cellular and non-cellular (e.g., non-3GPP access). Note that as shown, the <NUM> MM may maintain individual connection management and registration management state machines for each connection. Additionally, a device (e.g., UE <NUM>) may register to a single PLMN (e.g., <NUM> CN) using <NUM> cellular access as well as non-cellular access. Further, it may be possible for the device to be in a connected state in one access and an idle state in another access and vice versa. Finally, there may be common <NUM>-MM procedures (e.g., registration, de-registration, identification, authentication, as so forth) for both accesses.

Note that in various embodiments, one or more of the above described functional entities of the <NUM> NAS and/or <NUM> AS may be configured to perform methods utilization of an inter-UE coordination message, e.g., for V2X Mode <NUM> resource allocation, e.g., as further described herein.

<FIG> illustrates an example block diagram of a base station <NUM> (e.g., base station 102A in <FIG>), according to some embodiments.

The network port <NUM> may be configured to couple to a telephone network and provide a plurality of devices, such as UE devices <NUM>.

The radio <NUM> may be configured to communicate via various wireless communication standards, including, but not limited to, <NUM> NR, LTE, LTE-A, GSM, UMTS, CDMA2000, Wi-Fi, and so forth.

As another example, the base station <NUM> may include a <NUM> NR radio for performing communication according to <NUM> NR as well as a Wi-Fi radio for performing communication according to Wi-Fi. In such a case, the base station <NUM> may be capable of operating as both <NUM> NR base station and a Wi-Fi access point. As a further possibility, the base station <NUM> may include a multi-mode radio which is capable of performing communications according to any of multiple wireless communication technologies (e.g., <NUM> NR and Wi-Fi, LTE and Wi-Fi, LTE and UMTS, LTE and CDMA2000, UMTS and GSM, and so forth).

In addition, each integrated circuit may include circuitry (e.g., first circuitry, second circuitry, and so forth) configured to perform the functions of processor(s) <NUM>.

In addition, each integrated circuit may include circuitry (e.g., first circuitry, second circuitry, and so forth) configured to perform the functions of radio <NUM>.

In some existing implementations, a listen before talk (LBT) mechanism may be used to access shared medium (e.g., such as 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., of transmissions emanating from two or more wireless devices attempting to access the shared medium) and to improve medium utilization efficiency. However, LBT mechanisms are not collision free. In other words, LBT mechanisms cannot guarantee collision free transmissions.

For example, in the case of a unicast transmission, a transmitter may readily detect a transmission collision based on a receiver's acknowledgement/negative acknowledgement (ACK/NACK) feedback. However, in the case of a multicast (or group-cast) transmission, a transmitter may not easily detect a collision based on receivers' ACK/NACKs due, at least in part, to heavy traffic associated with ACK/NACKs from multiple receivers and to a transmitter's inability to distinguish between (or isolate) transmission collisions from channel quality issues based on received ACK/NACKs. In other words, since receivers in a multicast transmission may have different locations with differing channel quality, a reason for a NACK (e.g., transmission collision versus poor channel quality) cannot be determined by the transmitter. Additionally, in the case of a broadcast transmission, feedback from receivers is known to not be feasible, so in this scenario, a transmitter would not have knowledge of collisions. Further, in some implementations, a transmitter may reserve periodic slots within a reservation period for communication. In such implementations, if collisions occur, the collisions could persist for at least a portion of the reservation period (and in a worst-case scenario, the duration of the reservation period) if the transmitter does not detect (or is unable to detect) the collisions.

As an example, vehicle-to-everything (V2X) communications, e.g., as specified by 3GPP TS <NUM> V. <NUM> and beyond, allows for communication between a vehicle (e.g., a mobile unit within a vehicle, such as a wireless device comprised within or currently contained within a vehicle and/or another transmitter contained or comprised with a vehicle) and various wireless devices. For example, as illustrated by <FIG>, a vehicle, such as vehicle 712a, may communicate with various devices (e.g., devices 712b-f), such as road side units (RSUs), infrastructure (V2I), network (V2N), pedestrian (V2P), and/or other vehicles (V2V). In addition, as shown, all devices within the 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 communications (e.g., non-cellular). In some contemplated implementations, the non-cellular communications may use unlicensed bands as well as a dedicated spectrum at <NUM>. Moreover, V2X communications may include unicast, multicast, groupcast, and/or broadcast communications. Each communication type may employ an LBT mechanism. Further, 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 communications, may, in some instances, be unable to detect collisions after using an LBT mechanism.

In some existing implementations, <NUM> NR V2X may include various scheduling modes. For example, <NUM> NR V2X mode <NUM> may be designed for UE self-determination of sidelink transmission resources. <NUM> NR V2X mode <NUM> includes various sub-modes, including:.

In addition, due to the periodic nature of V2X messaging, existing implementations of V2X may support semi-persistent scheduling (SPS), e.g., configured grant(s). For example, semi-persistent resources in SPS may represent timely repeated resources across a set of discontinuous subframes with a certain repetition periodicity. Further, existing implementations of SPS (e.g., LTE V2X) and its corresponding resource allocation design are optimized for broadcast service. However, <NUM> NR V2X mode <NUM> additionally supports both unicast and groupcast services. Thus, there is a strong need to enhance methods that aid semi-persistent resource allocation for unicast service and groupcast service in <NUM> NR V2X mode <NUM>.

In current cellular communication systems, e.g., such as defined by NR V2X Release <NUM>, for a Mode <NUM> resource allocation scheme, a transmitting wireless device may select sidelink transmission resources based on its own sensing and resource selection procedure, e.g., without input from the receiving wireless device. NR V2X Release <NUM> introduced that, for inter-UE coordination of Mode <NUM> resource allocations, a set of resources may be determined by a first wireless device (e.g., UE-A) and sent to a second wireless device (UE-B). The second wireless device may then take the set of resources into account in a resource selection for its own transmission.

In order to determine the set of resources, candidate resources are identified within a resource selection window. Note that a resource may be excluded if it is reserved and the associated RSRP measurement is above a threshold, where an initial RSRP threshold is pre-configured for each combination of a priority of data for transmission and a priority of data reserving the resource. Identification may be stopped when a number of identified candidate resources is more than X% of the number of all resources in the resource selection window in the resource pool. Note that X can be <NUM>, <NUM>, and/or <NUM> and can be pre-configured per resource pool per L1 priority. Note further that if a number of identified candidate resources is not more than X% of the number of all resources in the resource selection window in the resource pool upon completion of the identification process, the RSRP threshold (initial and/or current) may be increased by <NUM> dB and the identification procedure may be repeated. Once the resource set is identified, it may be transmitted to the second wireless device. The second wireless device may perform a randomized resource selection based on the resource set and ensure a minimum time gap between any two selected resources of a TB where HARQ feedback for the first of these resources is expected.

In particular, a total number of candidate single-slot resources within the resource selection window may be set as Mtotal. Additionally, a sensing window may be defined via sensing operations and an internal RSRP threshold for resource exclusion may set. Further, the set of all candidate single-slot resources may be initially set as SA and the first wireless device may exclude any candidate single-slot resource from SA due to slots not monitored and/or due to the resource reservation conflict (e.g., resource reserved by sidelink control information (SCI) and/or RSRP of the physical sidelink control channel (PSCCH) or the physical sidelink shared channel (PSSCH) associates with the reservation SCI is larger than the RSRP threshold). Then, if a number of candidate single-slot resource in SA is less than a product of X and Mtotal, increase the RSRP threshold by <NUM> dB and repeat the exclusion process. Otherwise, the SA without the excluded resources may be reported to higher layers.

However, the second wireless device's behavior after receiving the set of resources remains undefined. For example, behaviors left undefined include the second wireless device's resource selection procedure upon receiving the set of resources, second wireless device's resource reevaluation procedure upon receiving the set of resources, as well as the second wireless device's resource pre-emption check upon receiving the set of resources. Additionally, it has not been defined whether the second wireless device will have different behaviors depending on the contents of the set of resources.

Embodiments described herein provide systems, methods, and mechanisms for utilization of an inter-UE coordination message, e.g., for V2X Mode <NUM> resource allocation. In some embodiments, a UE, such as UE <NUM>, may receive an inter-UE coordination message from a coordinating UE, where the inter-UE coordination message may indicate a set of resources for the UE. Upon receipt of the inter-UE coordination message, the UE's behavior may depend on a category of the coordinating UE. For example, if the coordinating UE is a helper UE, e.g., which sends the set of resources for the UE's reference, the UE may have flexibility in its resource selection procedure. As another example, if the coordinating UE is a controlling UE, the UE may be required to follow the set of resources indicated in the inter-UE coordination message. Additionally, upon receipt of the inter-UE coordination message, the UE's behavior may depend on contents of the inter-UE coordination message. For example, if and/or when the inter-UE coordination message includes assistance information (e.g., such as cause of not preferring certain resources) along with the set of resources, then UE may have flexibility in its resource selection procedure (e.g., the UE may not be restricted to following the recommended resources in the inter-UE coordination message). Further, upon receipt of the inter-UE coordination message, the UE's behavior may depend on a time of receipt of the inter-UE coordination message. For example, if and/or when the inter-UE coordination message is received within a configured time threshold before a planned sidelink transmission, then UE may not have enough time to process and apply the resources in the inter-UE coordination message. Hence, the UE may not perform resource re-evaluation and/or resource pre-emption operations.

In some embodiments, a UE, such as UE <NUM>, may receive an inter-UE coordination message that includes an indication of non-preferred resources. Based on the indication of non-preferred resources, the UE may perform resource selection and/or resource reselection, e.g., via a re-evaluation procedure. For example, <FIG> illustrate block diagrams of examples of such procedures, according to some embodiments. Note that the methods shown in <FIG> may be used in conjunction with one another as well as with any of the systems, methods, or devices shown in the Figures, among other devices. Note that in the embodiments described herein, the inter-UE coordination message may be transmitted from a coordinating UE to the UE, where the coordinating UE determines a set of resources to indicate via the inter-UE coordination message. and where the set of resources are used by the UE for sidelink transmissions.

Turning to <FIG>, illustrated is a block diagram of an example of method for a UE to perform resource selection with non-preferred resources indicated in an inter-UE coordination message, according to some embodiments. Note that the method shown in <FIG> may be used in conjunction with one another as well as with any of the systems, methods, or devices shown in the Figures, among other devices. In various embodiments, some of the method elements shown may be performed concurrently, in a different order than shown, or may be omitted. Additional method elements may also be performed as desired. As shown, this method may operate as follows.

At <NUM>, a UE, such as UE <NUM>, may receive, from a coordinating UE, a set of non-preferred resources via an inter-UE coordination message. At this point, the UE may not have selected sidelink resources, thus the UE may apply the set of-non-preferred resources as part of a resource selection procedure. Thus, the UE may identify a set of resources within a resource selection window. Then, at <NUM>, the UE may exclude the non-preferred resources from the set of resources for sidelink transmission to generate a set of candidate resources. For example, in some embodiments, a physical layer of the UE may identify the set of resources within the resource selection window (e.g., based on sensing) and pass the set of resources to a MAC layer of the UE. The MAC layer may then generate the set of candidate resources, e.g., via exclusion on the non-preferred resources. As another example, in some embodiments, the physical layer of the UE may identify the set of resources within the resource selection window (e.g., based on sensing) and receive the non-preferred resources from the MAC layer of the UE which are indicated in the inter-UE coordination message. The physical layer may then generate the set of candidate resources, e.g., via exclusion on the non-preferred resources and pass the candidate resources to the MAC layer. Note that, depending on a category of the first UE and/or assistance information (e.g., such as RSRP for the set of resources and/or data priority of the set of resources), not all resources from the non-preferred resources may be excluded from the set of resources. For example, the UE may determine that based on the category of the first UE, that it is not required to follow all of the first UE's suggested resource selections. As another example, based on the assistance information, the UE may determine that a non-preferred resource may be preferable to the UE, e.g., based on RSRP sensed by the UE. At <NUM>, the UE may perform a random resource selection procedure on the set of candidate resources, e.g., to determine a set of resources to use for sidelink communications. In at least some instances, the MAC layer may perform the random resource selection procedure.

Turning to <FIG>, illustrated is a block diagram of an example of a method for a UE to perform resource re-selection with non-preferred resources indicated in an inter-UE coordination message, according to some embodiments. As noted, the method shown in <FIG> may be used in conjunction with any of the systems, methods, or devices shown in the Figures, among other devices. In various embodiments, some of the method elements shown may be performed concurrently, in a different order than shown, or may be omitted. Additional method elements may also be performed as desired. As shown, this method may operate as follows.

At <NUM>, a UE, such as UE <NUM>, may receive, from a coordinating UE, a set of non-preferred resources via an inter-UE coordination message. The UE may have previously selected a set of resources, e.g., based on a prior and/or previous set of resources indicated via a previous and/or prior inter-UE coordination message. Note that in some embodiments, the UE may have not yet reserved the selected resources prior to receipt of the inter-UE coordination message. In some embodiments, the UE may have reserved the selected resources prior to receipt of the inter-UE coordination message. The inter-UE coordination message may include assistance information.

At <NUM>, the UE may update a set of selected resources based on the inter-UE coordination message and whether the UE has already reserved the selected resources. For example, if the UE has not reserved the selected resources, the UE may exclude the non-preferred resources from the selected set of resources to generate a set of updated resources. In other words, the UE may update the selected resources by excluding intersections between the selected set of resources and the set of non-preferred resources. Note that if after, exclusion the updated set of resources is a strict subset of selected set of resources, then the UE may trigger a resource selection procedure at <NUM>. Note further, that if assistance information is included in the inter-UE coordination message, the UE may take the assistance information into account during the exclusion process, e.g., as described above. As another example, if the UE has reserved the selected resources (e.g., via SCI signaling), the UE may pass the selected and reserved resources to the physical layer as well as the set of non-preferred resources. Then, the physical layer may perform a pre-emption check on the selected resources at <NUM>, wherein the set of non-preferred resources may be treated as reserved resources by other UEs, with RSRP level and data priority in an associated SCI being provided via the inter-UE coordination message.

At <NUM>, the UE may perform a resource selection procedure on the set of updated resources, e.g., to determine a set of resources to use for sidelink communications.

In some embodiments, a UE, such as UE <NUM>, may receive an inter-UE coordination message that includes an indication of preferred resources. Based on the indication of preferred resources, the UE may perform resource selection and/or resource reselection, e.g., via a re-evaluation procedure. For example, <FIG> and <FIG> illustrate block diagrams of examples of such procedures, according to some embodiments. Note that the methods shown in <FIG> and <FIG> may be used in conjunction with one another as well as with any of the systems, methods, or devices shown in the Figures, among other devices. Note that in the embodiments described herein, the inter-UE coordination message may be transmitted from a coordinating UE to the UE, where the coordinating UE determines a set of resources to indicate via the inter-UE coordination message. and where the set of resources are used by the UE for sidelink transmissions.

Turning to <FIG>, illustrated is a block diagram of an example of method for a UE to perform resource selection with preferred resources indicated in an inter-UE coordination message, according to some embodiments. Note that the method shown in <FIG> may be used in conjunction with one another as well as with any of the systems, methods, or devices shown in the Figures, among other devices. In various embodiments, some of the method elements shown may be performed concurrently, in a different order than shown, or may be omitted. Additional method elements may also be performed as desired. As shown, this method may operate as follows.

At <NUM>, a UE, such as UE <NUM>, may receive, from a coordinating UE, a set of preferred resources via an inter-UE coordination message. At this point, the UE may not have selected sidelink resources, thus the UE may apply the set of-non-preferred resources as part of a resource selection procedure. Thus, the UE may identify a set of resources within a resource selection window at <NUM>. Thus, the UE may perform a candidate resource selection procedure based on a resource selection window to generate a set of candidate resources. In some embodiments, a physical layer of the UE may perform the resource selection procedure, e.g., based on sensing (measurement) of resources at the UE. Then, at <NUM>, the UE may determine an interaction set of resources based on a comparison of the set of preferred resources to the set of candidate resources. In some embodiments, the physical layer may pass the set of candidate resources to a MAC layer of the UE and the MAC layer may determine the interaction set.

At <NUM>, the UE may perform a resource selection procedure on the interaction set of resources, e.g., to determine a set of resources to use for sidelink communications. In some embodiments, if a cardinality of the interaction set of resources is equal to a number of resources to be selected, then the determined set of resources may be the interaction set of resources. Alternatively, if the cardinality of the interaction set of resources is less than the number of resources to be selected, then besides the intersection set of resources, additional resources, up to the number of resources to be selected, may be randomly selected from the set of candidate resources excluding the interaction set of resources. Further, if the cardinality of the interaction of resources is greater than the number of resources to be selected, then the determined set of resources may be randomly selected from the interaction set of resources. Alternatively, if assistance information included in the inter-UE coordination message includes ranking of the set of preferred resources, then the determined set of resources may be selected in order of ranking, with higher ranked resources selected prior to lower ranked resources.

Turning to <FIG>, illustrated is a block diagram of an example of a method for a UE to perform resource re-evaluation with preferred resources indicated in an inter-UE coordination message, according to some embodiments. As noted, the method shown in <FIG> may be used in conjunction with any of the systems, methods, or devices shown in the Figures, among other devices. In various embodiments, some of the method elements shown may be performed concurrently, in a different order than shown, or may be omitted. Additional method elements may also be performed as desired. As shown, this method may operate as follows.

At <NUM>, a UE, such as UE <NUM>, may receive, from a coordinating UE, a set of preferred resources via an inter-UE coordination message. The UE may have previously selected a set of resources, e.g., based on a prior and/or previous set of resources indicated via a previous and/or prior inter-UE coordination message. Note that in some embodiments, the UE may have not yet reserved the selected resources prior to receipt of the inter-UE coordination message. In some embodiments, the UE may have reserved the selected resources prior to receipt of the inter-UE coordination message. The inter-UE coordination message may include assistance information.

At <NUM>, the UE may perform a resource re-evaluation and/or re-selection procedure based on the set of preferred resources. For example, the UE may treat the preferred set of resources as selected resources which need re-evaluation.

At <NUM>, the UE may select a desired number of resources from the preferred resource set. In some embodiments, the UE may rank the set of preferred resources based on sensing, e.g., as performed by the UE. The UE may then select the desired number of highest ranked preferred resources, e.g., to determine a set of resources to use for sidelink communications. Alternatively, the UE may randomly select the desired number of resources from the preferred resource set.

<FIG> illustrates a block diagram of an example of a method for utilization of an inter-UE coordination message, according to some embodiments. The method shown in <FIG> may be used in conjunction with any of the systems, methods, or devices shown in the Figures, among other devices. In various embodiments, some of the method elements shown may be performed concurrently, in a different order than shown, or may be omitted. Additional method elements may also be performed as desired. As shown, this method may operate as follows.

At <NUM>, a UE, such as UE <NUM>, may receive, from a first UE, an inter-UE coordination message. The inter-UE coordination message may include an indication of a set of resources and an indication of whether the set of resources are preferred resources or non-preferred resources.

At <NUM>, the UE may select resources for sidelink communications based on the set of resources indicated in the inter-UE coordination message. In other words, the UE may perform differing selection processes based on the set of resources indicated in the inter-UE coordination message. Thus, for example, the UE may perform a first process and/or set of processes when the set of resources are indicated as non-preferred and a second process and/or sect of processes when the set of resources are indicated as preferred, e.g., as further described herein.

In some embodiments, the UE may determine resources available for sidelink communication and, when the set of resources are indicated as non-preferred (e.g., via the inter-UE coordination message), exclude at least a portion of the set of resources from the determined resources available for sidelink communication to generate a candidate resource set. In some embodiments, selecting resources for sidelink communications may include randomly selecting resources from the candidate resource set. In some embodiments, a physical layer of the UE may determine the resources available for sidelink communication and may pass the resources available for sidelink communication to a medium access control (MAC) layer of the UE. The MAC layer of the UE may generate the candidate resource set and may perform selection of the resources for sidelink communications. In some embodiments, the physical layer of the UE may determine the resources available for sidelink communication and may receive the set of resources from the MAC layer of the UE. The physical layer of the UE may generate the candidate resource set and may pass the candidate resource set to the MAC layer. The MAC layer may perform selection of the resources for sidelink communications.

In some embodiments, the UE may determine resources available for sidelink communication and, when the set of resources are indicated as preferred (e.g., via the inter-UE coordination message), determine an interaction set of resources based on a comparison of the resources available for sidelink communication and the set of resources. In some embodiments, selecting resources for sidelink communications may include randomly selecting resources from the interaction set of resources. Additionally, when a number of resources to be selected is less than the number of resources in the interaction set of resources and the inter-UE coordination message includes an indication of a ranking of resources within the set of resources, selecting resources for sidelink communication may include selecting resources from the interaction set of resources based on indicated rank of resources within the set of resources. The resources may be selected from highest rank in decreasing order up to the number of resources to be selected. In some embodiments, a physical layer of the UE may determine the resources available for sidelink communication and may pass the resources available for sidelink communication to the MAC layer of the UE. The MAC layer of the UE may generate the interaction set and may perform selection of the resources for sidelink communications.

In some embodiments, the UE may receive, from the first UE prior to reserving the selected sidelink resources, a second inter-UE coordination message. The second inter-UE coordination message may include an indication of a second set of resources and an indication that the second set of resources are non-preferred resources. The UE may exclude, based on a comparison of the selected sidelink resources and the second set of resources, resources in the selected sidelink resources indicated as non-preferred by the second set of resources. In some embodiments, when the second set of resources is a strict subset of the selected resources, the UE may randomly select resources from the excluded resources up to a number of resources required for selection. In some embodiments, when the second set of resources is a strict subset of the selected resources and assistance information is provided by the first UE, the UE may select resources from the excluded resources up to a number of resources required for selection based, at least in part, on the assistance information. The assistance information may include at least a reference signal received power (RSRP) for each resource in the second set of resources.

In some embodiments, the UE may receive, from the first UE after reserving the selected sidelink resources, a second inter-UE coordination message. The second inter-UE coordination message may include an indication of a second set of resources and an indication that the second set of resources are non-preferred resources. The UE may exclude, based on a comparison of the selected sidelink resources and the second set of resources, resources in the selected sidelink resources indicated as non-preferred by the second set of resources. In some embodiments, the second inter-UE coordination message may further include assistance information for the second set of resources.

In some embodiments, the UE may receive, from the first UE after selecting the sidelink resources, a second inter-UE coordination message. The second inter-UE coordination message may include an indication of a second set of resources and an indication that the second set of resources are preferred resources. The UE may select resources in the second set of resources based on interference level. The resources may be selected up to a number of required resources in order of decreasing rank. The UE may reserve the resources selected from the second set.

In some embodiments, the UE may receive, from the first UE after selecting the sidelink resources, a second inter-UE coordination message. The second inter-UE coordination message may include an indication of a second set of resources and an indication that the second set of resources are preferred resources. The UE may randomly select resources from the second set of resources up to a number of required resources. The UE may reserve the resources selected from the second set.

In some embodiments, a device (e.g., a UE <NUM>) may be configured to include a processor (or a set of processors) and a memory medium, where the memory medium stores program instructions, where the processor is configured to read and execute the program instructions from the memory medium, where the program instructions are executable to implement 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 realized in any of various forms.

Claim 1:
A method for utilization of an inter-user equipment device, inter-UE, coordination message, comprising:
a UE (<NUM>),
receiving (<NUM>), from a first UE, a first inter-UE coordination message, wherein the first inter-UE coordination message includes an indication of a first set of resources and an indication of whether the first set of resources are preferred resources or non-preferred resources; and
selecting (<NUM>) resources for sidelink communications based on the first set of resources indicated in the inter-UE coordination message,
characterized in that the method further comprises:
the UE (<NUM>),
receiving, from the first UE prior to reserving the selected sidelink resources, a second inter-UE coordination message, wherein the second inter-UE coordination message includes an indication of a second set of resources and an indication that the second set of resources are non-preferred resources; and
excluding, based on a comparison of the selected sidelink resources and the second set of resources, resources in the selected sidelink resources indicated as non-preferred by the second set of resources.