Connectivity assisted driving strategy

Abstract

Techniques for wireless communication are disclosed. In an aspect, a first Internet of Vehicles (V2X)-capable vehicle receives, from a V2X-capable device, one or more V2X messages indicating an intended driving path of a second V2X-capable vehicle; and determining a feasible driving trajectory of the first V2X-capable vehicle from a plurality of potential driving trajectories of the first V2X-capable vehicle based at least in part on the intended driving path of the second V2X-capable vehicle.

Description

TECHNICAL FIELD

[0001] Aspects of the disclosure relate generally to wireless communication. BACKGROUND

[0002] Wireless communication systems have developed through various generations, including first-generation analog wireless phone services, second-generation (2G) digital wireless phone services (including 2.5G and 2.75G networks), third-generation (3G) high speed data, Internet-capable wireless services, and fourth-generation (4G) services (e.g., Long-Term Evolution (LTE) or WiMax). There are now a number of different types of wireless communication systems in use, including cellular and personal communications service (PCS) systems. Examples of known cellular systems include the cellular Analog Advanced Mobile Phone System (AMPS), and digital cellular systems based on code division multiple access (CDMA), frequency division multiple access (FDMA), time division multiple access (TDMA), Global System for Mobile communications (GSM), etc.

[0003] The fifth generation (5G) wireless standard, referred to as New Radio (NR), enables higher data transfer speeds, greater numbers of connections, and better coverage than previous standards. According to the Next Generation Mobile Networks Alliance, 5G technology should provide data transfer rates of several tens of megabits per second to each of several tens of users, with the ability to connect to hundreds of thousands of users in macro cells and provide service to tens of thousands of users in small cells. It should also be able to support more compact cells to increase network capacity.

[0004] In addition, with the increased data rates and reduced latency of 5G, vehicle-to-everything (V2X) communication technologies are being implemented to support autonomous driving applications, such as wireless communications between vehicles, vehicles and roadside infrastructure, vehicles and pedestrians, etc. SUMMARY

[0005] The following presents a simplified summary related to one or more aspects disclosed herein. Thus, the following summary should not be considered an extensive overview relating to all contemplated aspects, nor should the following summary be considered to identify key or critical elements relating to all contemplated aspects or to delineate the scope associated with any particular aspect. Accordingly, the following summary has the sole purpose to present certain concepts relating to one or more aspects disclosed herein in a simplified form to precede the detailed description presented below.

[0006] In one aspect, a method of wireless communication performed by a first vehicle-to-everything (V2X) capable vehicle includes: receiving one or more V2X messages from a V2X capable device indicating an intended driving path of a second V2X capable vehicle; and determining a feasible driving trajectory of the first V2X capable vehicle from a plurality of potential driving trajectories of the first V2X capable vehicle, based at least in part on the intended driving path of the second V2X capable vehicle.

[0007] In one aspect, a first vehicle-to-everything (V2X) capable vehicle includes: one or more memories; one or more transceivers; and one or more processors communicatively coupled to the one or more memories and the one or more transceivers, the one or more processors being individually or in combination configured to: receive, via the one or more transceivers, one or more V2X messages indicating an intended driving path of a second V2X capable vehicle from a V2X capable device; and determine a feasible driving trajectory of the first V2X capable vehicle from a plurality of potential driving trajectories of the first V2X capable vehicle, based at least in part on the intended driving path of the second V2X capable vehicle.

[0008] In one aspect, a first vehicle-to-everything (V2X) capable vehicle includes: components for receiving one or more V2X messages from a V2X capable device indicating an intended driving path of a second V2X capable vehicle; and components for determining a feasible driving path of the first V2X capable vehicle from a plurality of potential driving paths of the first V2X capable vehicle, based at least in part on the intended driving path of the second V2X capable vehicle.

[0009] In one aspect, a non-transitory computer-readable medium storing computer-executable instructions, which, when executed by a first vehicle-to-everything (V2X) capable vehicle, cause the first V2X capable vehicle to: receive from a V2X capable device one or more V2X messages indicating an intended driving path of a second V2X capable vehicle; and determine a feasible driving trajectory of the first V2X capable vehicle from a plurality of potential driving trajectories of the first V2X capable vehicle, at least in part based on the intended driving path of the second V2X capable vehicle.

[0010] Based on the accompanying drawings and detailed description, other objects and advantages associated with the aspects disclosed herein will be apparent to those skilled in the art. Attached Figure Description

[0011] The accompanying drawings are provided to help describe various aspects of this disclosure, and are provided for illustrative purposes only and not to limit the aspects.

[0012] Figure 1 Example wireless communication systems according to one or more aspects of this disclosure are illustrated.

[0013] Figure 2A and Figure 2B Example wireless network architectures according to one or more aspects of this disclosure are illustrated.

[0014] Figure 3A It is a top view of a vehicle employing an integrated radar camera sensor behind the windshield, according to one or more aspects of this disclosure.

[0015] Figure 3B An example onboard computer (OBC) architecture according to one or more aspects of this disclosure is illustrated.

[0016] Figure 4A , Figure 4B and Figure 4C It is a simplified block diagram of several examples of components that can be used in user equipment (UE), base stations and network entities and configured to support communications as taught herein.

[0017] Figure 5 This is a diagram illustrating an example driving strategy pipeline according to one or more aspects of this disclosure.

[0018] Figure 6 This is a diagram illustrating an example driving strategy prediction and stochastic programming scenario according to one or more aspects of this disclosure.

[0019] Figure 7A and Figure 7B Examples are illustrated of various scenarios that a driving strategy engine of a self-driving vehicle may encounter when performing autonomous or semi-autonomous driving maneuvers, according to one or more aspects of this disclosure.

[0020] Figure 8 This is an illustration of trajectory generation in an example driving scenario based on one or more aspects of this disclosure.

[0021] Figure 9 This is an illustration of an example driving scenario according to one or more aspects of this disclosure, in which a Basic Safety Message (BSM) can be used to trim possible route trajectories.

[0022] Figure 10 This is an illustration of an example driving scenario according to one or more aspects of this disclosure, in which collective perception messages (CPM) can be used to trim possible route trajectories.

[0023] Figure 11 This is an illustration of another example driving scenario according to one or more aspects of this disclosure, where CPM can be used to trim possible route trajectories.

[0024] Figure 12A and Figure 12B An example driving scenario according to one or more aspects of this disclosure is illustrated, in which manipulation sharing and coordination messages (MSCM) can be used to trim possible route trajectories.

[0025] Figure 13A and Figure 13B An example driving scenario according to one or more aspects of this disclosure is illustrated, in which distributed environmental notification messages (DENM) can be used to trim possible route trajectories.

[0026] Figure 14A to Figure 14C Example driving scenarios according to one or more aspects of this disclosure are illustrated, in which various vehicle-to-everything (V2X) messages can be used to trim possible route trajectories.

[0027] Figure 15 This is a diagram illustrating an example driving strategy pipeline for implementing V2X-based trajectory processing according to one or more aspects of this disclosure.

[0028] Figure 16 to Figure 20 Example methods of wireless communication according to one or more aspects of this disclosure are illustrated. Detailed Implementation

[0029] Various aspects of this disclosure are provided in the following description and accompanying drawings of various examples provided for illustrative purposes. Alternative aspects may be devised without departing from the scope of this disclosure. Furthermore, well-known elements of this disclosure will not be described in detail or will be omitted so as not to obscure the relevant details of this disclosure.

[0030] The various aspects collectively involve connectivity-assisted driving strategies for autonomous or semi-autonomous vehicles. Some aspects are more specifically related to determining feasible trajectories for autonomous or semi-autonomous vehicles based on one or more vehicle-to-everything (V2X) messages received from other V2X-capable vehicles or roadside infrastructure (e.g., roadside units (RSUs)). In some examples, information received in one or more Basic Safety Messages (BSMs) can be used to determine feasible route trajectories. In some examples, information received in one or more Collective Perception Messages (CPMs) can be used to determine feasible route trajectories. In some examples, information received in one or more Maneuver Sharing and Coordination Messages (MSCMs) can be used to determine feasible route trajectories. In some examples, information received in one or more Distributed Environment Notification Messages (DENMs) can be used to determine feasible route trajectories. In some examples, feasible trajectories determined based on information received in one or more BSMs, CPMs, MSCMs, DENMs, or any combination thereof can be shared with other V2X vehicles or roadside infrastructure.

[0031] Specific aspects of the subject matter described in this disclosure can be implemented to achieve one or more of the following potential advantages. In some examples, the described techniques can be used to improve route planning by using V2X messages to determine feasible trajectories. For example, by providing information from V2X messages to a driving strategy, the driving strategy can determine feasible trajectories even in the absence of sensing information from perception sensors of autonomous or semi-autonomous vehicles. Furthermore, this information can be used to prune infeasible trajectories, thereby improving the resource utilization of the driving strategy.

[0032] The terms “exemplary” and / or “example” are used herein to mean “serving as an example, instance, or illustration.” Any aspect described herein as “exemplary” and / or “example” is not necessarily to be construed as superior to or better than other aspects. Similarly, the term “aspects of this disclosure” does not require that all aspects of this disclosure include the features, advantages, or modes of operation discussed.

[0033] Those skilled in the art will understand that any of a variety of different techniques and methods can be used to represent the information and signals described below. For example, data, instructions, commands, information, signals, bits, symbols, and chips that may be mentioned throughout the following description can be represented by voltage, current, electromagnetic waves, magnetic fields or magnetic particles, light fields or optical particles, or any combination thereof, depending in part on the specific application, in part on the desired design, in part on the corresponding technology, and so on.

[0034] Furthermore, many aspects are described according to a sequence of actions to be performed by elements of, for example, a computing device. It will be appreciated that the various actions described herein can be performed by specific circuitry (e.g., an application-specific integrated circuit (ASIC)), by program instructions executed by one or more processors, or by a combination of both. Additionally, the sequence of actions described herein can be considered to be entirely embodied in any form of non-transitory computer-readable storage medium storing a corresponding set of computer instructions that, when executed, will cause or command the associated processor of the device to perform the functionality described herein. Therefore, various aspects of this disclosure can be embodied in a variety of different forms, all of which are contemplated within the scope of the claimed subject matter. Furthermore, for each aspect described herein, any corresponding form of any such aspect may be described herein as, for example, "logic configured to perform the described actions."

[0035] As used herein, the terms “user equipment” (UE), “vehicle UE” (V-UE), “pedestrian UE” (P-UE), and “base station” are not intended to be specific to or otherwise limited to any particular radio access technology (RAT) unless otherwise stated. In general, a UE can be any wireless communication device used by a user to communicate over a wireless communication network (e.g., vehicle onboard computer, vehicle navigation device, mobile phone, router, tablet computer, laptop computer, asset location device, wearable device (e.g., smartwatch, glasses, augmented reality (AR) / virtual reality (VR) headset, etc.), vehicle (e.g., car, motorcycle, bicycle, etc.), Internet of Things (IoT) device, etc.). A UE can be mobile or can (e.g., at certain times) be stationary and can communicate with a radio access network (RAN). As used herein, the term “UE” can be interchangeably referred to as “mobile device,” “access terminal” or “AT,” “client device,” “wireless device,” “subscriber equipment,” “subscriber terminal,” “subscriber station,” “user terminal” or UT,” “mobile terminal,” “mobile station,” or variations thereof.

[0036] V-UE is a type of UE and can be any in-vehicle wireless communication device, such as a navigation system, alarm system, head-up display (HUD), onboard computer, in-vehicle infotainment system, automated driving system (ADS), advanced driver assistance system (ADAS), etc. Alternatively, V-UE can be a portable wireless communication device (e.g., cellular phone, tablet computer, etc.) carried by the driver or occupant of a vehicle. The term "V-UE" can refer to the in-vehicle wireless communication device or the vehicle itself, depending on the context. P-UE is a type of UE and can be a portable wireless communication device carried by a pedestrian (i.e., a user who is not driving or riding in a vehicle). Generally, the UE can communicate with the core network via the RAN, and through the core network, the UE can connect to external networks such as the Internet and to other UEs. Of course, other mechanisms for connecting the UE to the core network and / or the Internet are also possible, such as through wired access networks, wireless local area network (WLAN) networks (e.g., based on IEEE 802.11, etc.).

[0037] A base station can communicate with a UE by operating under one of several RATs based on the network in which it is deployed, and may alternatively be referred to as an Access Point (AP), Network Node, Node B, Evolved Node B (eNB), Next Generation eNB (ng-eNB), New Radio (NR) Node B (also known as gNB or gNodeB), etc. The base station is primarily used to support the UE's radio access, including supporting the UE's data, voice, and / or signaling connections. In some systems, the base station may only provide edge node signaling functions, while in others, it may provide additional control and / or network management functions. The communication link through which the UE can transmit signals to the base station is called an uplink (UL) channel (e.g., reverse traffic channel, reverse control channel, access channel, etc.). The communication link through which the base station can transmit signals to the UE is called a downlink (DL) or forward link channel (e.g., paging channel, control channel, broadcast channel, forward traffic channel, etc.). As used herein, the term Traffic Channel (TCH) may refer to either the UL / reverse or DL / forward traffic channel.

[0038] The term "base station" can refer to a single physical transmit / receive point (TRP) or multiple physical TRPs that may or may not be co-located. For example, when the term "base station" refers to a single physical TRP, the physical TRP can be the antenna of a base station corresponding to a cell (or several cell sectors) of the base station. When the term "base station" refers to multiple co-located physical TRPs, the physical TRP can be the antenna array of the base station (e.g., as in a multiple-input multiple-output (MIMO) system or where the base station employs beamforming). When the term "base station" refers to multiple non-co-located physical TRPs, the physical TRP can be a distributed antenna system (DAS) (a network of spatially separated antennas connected via a transmission medium to a common source) or a remote radio headend (RRH) (a remote base station connected to a serving base station). Alternatively, a non-co-located physical TRP can be the serving base station from which the UE receives measurement reports and a neighboring base station where the UE is measuring its reference radio frequency (RF) signal. Because, as used herein, a TRP is the point by which a base station transmits and receives radio signals, references to transmitting from or receiving at a base station should be understood to refer to a specific TRP of the base station.

[0039] In some specific implementations supporting UE positioning, the base station may not support the UE's radio access (e.g., it may not support the UE's data, voice, and / or signaling connections). Instead, it may send a reference RF signal to the UE for measurement by the UE, and / or receive and measure signals sent by the UE. Such a base station may be referred to as a positioning beacon (e.g., in the case of sending RF signals to the UE) and / or as a location measurement unit (e.g., in the case of receiving and measuring RF signals from the UE).

[0040] An “RF signal” refers to an electromagnetic wave of a given frequency that transmits information across the space between a transmitter and a receiver. As used herein, a transmitter may send a single “RF signal” or multiple “RF signals” to a receiver. However, due to the propagation characteristics of RF signals through multipath channels, a receiver may receive multiple “RF signals” corresponding to each transmitted RF signal. The same transmitted RF signal on different paths between the transmitter and receiver can be referred to as a “multipath” RF signal. As used herein, an RF signal may also be referred to as a “wireless signal” or simply a “signal” where the context clearly indicates that the term “signal” refers to a wireless signal or an RF signal.

[0041] Figure 1An example wireless communication system 100 according to various aspects of this disclosure is illustrated. The wireless communication system 100 (which may also be referred to as a wireless wide area network (WWAN)) may include various base stations 102 (labeled "BS") and various UEs 104. Base station 102 may include macro cell base stations (high-power cellular base stations) and / or small cell base stations (low-power cellular base stations). In one aspect, macro cell base station 102 may include eNB and / or ng-eNB (wherein wireless communication system 100 corresponds to an LTE network) or gNB (wherein wireless communication system 100 corresponds to an NR network) or a combination of both, and small cell base stations may include femtocells, picocells, microcells, etc.

[0042] Base station 102 can collectively form a RAN and interface with core network 170 (e.g., evolved packet core (EPC) or 5G core (5GC)) via backhaul link 122, and interface with one or more location servers 172 (e.g., location management function (LMF) or secure user plane positioning (SUPL) positioning platform (SLP)) via core network 170. Location server 172 can be part of core network 170 or can be external to core network 170. Location server 172 can be integrated with base station 102. UE 104 can communicate with location server 172 directly or indirectly. For example, UE 104 can communicate with location server 172 via base station 102 currently serving UE 104. UE 104 can also communicate with location server 172 via another path, such as via application server (not shown), via another network, such as via wireless local area network (WLAN) access point (AP) (e.g., AP 150 described below), etc. For signaling purposes, communication between UE 104 and location server 172 can be represented as an indirect connection (e.g., via core network 170, etc.) or a direct connection (e.g., as shown via direct connection 128), wherein intermediate nodes (if present) are omitted from the signaling diagram for clarity.

[0043] In addition to other functions, base station 102 may perform functions associated with one or more of the following: transmitting user data, radio channel encryption and decryption, integrity protection, header compression, mobility control functions (e.g., handover, dual connectivity), inter-cell interference coordination, connection establishment and release, load balancing, distribution of Non-Access Stratum (NAS) messages, NAS node selection, synchronization, RAN sharing, Multimedia Broadcast Multicast Service (MBMS), subscriber and equipment tracking, RAN Information Management (RIM), paging, location, and delivery of warning messages. Base stations 102 may communicate with each other directly or indirectly (e.g., via EPC / 5GC) on backhaul link 134, which may be wired or wireless.

[0044] Base station 102 can wirelessly communicate with UE 104. Each base station in base station 102 can provide communication coverage for a corresponding geographical coverage area 110. In one aspect, one or more cells can be supported by base station 102 in each geographical coverage area 110. A “cell” is a logical communication entity used to communicate with a base station (e.g., via a frequency resource, which is referred to as a carrier frequency, component carrier, carrier, frequency band, etc.) and can be associated with an identifier (e.g., Physical Cell Identifier (PCI), Enhanced Cell Identifier (ECI), Virtual Cell Identifier (VCI), Cell Global Identifier (CGI), etc.) used to distinguish cells operating via the same or different carrier frequencies. In some cases, different cells can be configured according to different protocol types that can provide access for different types of UEs (e.g., Machine Type Communication (MTC), Narrowband IoT (NB-IoT), Enhanced Mobile Broadband (eMBB), or other protocol types). Because a cell is supported by a specific base station, the term “cell” can refer to one or both of the logical communication entity and the base station that supports it, depending on the context. In some cases, the term "cell" can also refer to the geographical coverage area of ​​a base station (e.g., a sector), as long as the carrier frequency can be detected and used for communication within a certain part of the geographical coverage area 110.

[0045] While the geographic coverage areas 110 of adjacent macro cell base stations 102 may partially overlap (e.g., in handover areas), some areas within geographic coverage areas 110 may substantially overlap with larger geographic coverage areas 110. For example, a small cell base station 102' (labeled "SC" for "small cell") may have geographic coverage areas 110' that substantially overlap with the geographic coverage areas 110 of one or more macro cell base stations 102. A network that includes both small cell base stations and macro cell base stations can be referred to as a heterogeneous network. A heterogeneous network may also include a home eNB (HeNB) that can provide service to a restricted group referred to as a Closed Subscriber Group (CSG).

[0046] The communication link 120 between base station 102 and UE 104 may include uplink (also known as reverse link) transmission from UE 104 to base station 102 and / or downlink (DL) (also known as forward link) transmission from base station 102 to UE 104. The communication link 120 may use MIMO antenna techniques, including spatial multiplexing, beamforming, and / or transmit diversity. The communication link 120 may use one or more carrier frequencies. Carrier allocation may be asymmetric for the downlink and uplink (e.g., more or fewer carriers may be allocated to the downlink compared to the uplink).

[0047] The wireless communication system 100 may also include a WLAN access point (AP) 150 that communicates with a wireless local area network (WLAN) station (STA) 152 via a communication link 154 in unlicensed spectrum (e.g., 5 GHz). When communicating in unlicensed spectrum, the WLAN STA 152 and / or WLAN AP 150 may perform a free channel assessment (CCA) or listen-before-talk (LBT) process before communication to determine whether the channel is available.

[0048] Small cell base station 102' can operate in licensed and / or unlicensed spectrum. When operating in unlicensed spectrum, small cell base station 102' can employ LTE or NR technology and use the same 5GHz unlicensed spectrum as WLAN AP 150. Small cell base station 102' employing LTE / 5G in unlicensed spectrum can improve the coverage and / or increase the capacity of the access network. NR in unlicensed spectrum may be referred to as NR-U. LTE in unlicensed spectrum may be referred to as LTE-U, Licensed Assisted Access (LAA), or MULTEFIRE. ® .

[0049] The wireless communication system 100 may also include an mmW base station 180, which can operate in millimeter-wave (mmW) frequencies and / or near-mmW frequencies to communicate with the UE 182. Extremely high frequency (EHF) is a portion of the electromagnetic spectrum that contains radio frequency (RF). EHF has a range of 30 GHz to 300 GHz, with wavelengths between 1 mm and 10 mm. Radio waves in this band can be referred to as millimeter waves. Near-mmW can extend down to frequencies of 3 GHz with wavelengths of 100 mm. Ultra-high frequency (SHF) bands extend between 3 GHz and 30 GHz, and are also referred to as centimeter waves. Communication using mmW / near-mmW radio bands has high path loss and relatively short range. The mmW base station 180 and the UE 182 can utilize beamforming (transmit and / or receive) on the mmW communication link 184 to compensate for the extremely high path loss and short range. Furthermore, it should be understood that in alternative configurations, one or more base stations 102 may also use mmW or near-mmW and beamforming for transmission. Therefore, it should be understood that the foregoing examples are merely illustrative and should not be construed as limiting the various aspects disclosed herein.

[0050] Transmit beamforming is a technique used to focus RF signals in a specific direction. Traditionally, when a network node (e.g., a base station) broadcasts an RF signal, it broadcasts the signal in all directions (omnidirectionally). Using transmit beamforming, the network node determines where a given target device (e.g., a UE) is located (relative to the transmitting network node) and projects a stronger downlink RF signal in that specific direction, thus providing the receiving device with a faster and stronger RF signal (in terms of data rate). To change the directivity of the RF signal during transmission, the network node can control the phase and relative amplitude of the RF signal at each of one or more transmitters broadcasting the RF signal. For example, the network node can use an array of antennas (called a "phased array" or "antenna array") that forms an RF beam that can be "manipulated" to be pointed in different directions without actually moving the antennas. Specifically, RF currents from the transmitters are fed to individual antennas with the correct phase relationship, such that radio waves from the individual antennas add up in the desired direction to increase radiation, while canceling out in the undesired direction to suppress radiation.

[0051] Transmit beams can be quasi-co-located, meaning they appear to the receiver (e.g., the UE) as having the same parameters regardless of whether the network node's own transmit antennas are physically co-located. In NR, there are four types of quasi-co-located (QCL) relationships. Specifically, a given type of QCL relationship means that certain parameters of a second reference RF signal on a second beam can be derived based on information about the source reference RF signal on the source beam. Therefore, if the source reference RF signal is QCL type A, the receiver can use the source reference RF signal to estimate the Doppler shift, Doppler spread, average delay, and delay spread of the second reference RF signal transmitted on the same channel. If the source reference RF signal is QCL type B, the receiver can use the source reference RF signal to estimate the Doppler shift and Doppler spread of the second reference RF signal transmitted on the same channel. If the source reference RF signal is QCL type C, the receiver can use the source reference RF signal to estimate the Doppler shift and average delay of the second reference RF signal transmitted on the same channel. If the source reference RF signal is of type QCL D, the receiver can use the source reference RF signal to estimate the spatial reception parameters of a second reference RF signal transmitted on the same channel.

[0052] In receive beamforming, a receiver uses a receive beam to amplify an RF signal detected on a given channel. For example, the receiver may increase the gain setting of an antenna array in a particular direction and / or adjust the phase setting of the antenna array in a particular direction to amplify the RF signal received from that direction (e.g., increase its gain level). Therefore, when a receiver is described as performing beamforming in a certain direction, it means that the beam gain in that direction is high relative to the beam gain along other directions, or that the beam gain in that direction is the highest compared to the beam gain of all other receive beams available to the receiver in that direction. This results in a stronger received signal strength (e.g., reference signal received power (RSRP), reference signal received quality (RSRQ), signal-to-interference-plus-noise ratio (SINR), etc.) of the RF signal received from that direction.

[0053] The transmit and receive beams can be spatially correlated. Spatial correlation means that parameters for a second beam (e.g., transmit or receive beam) for a second reference signal can be derived based on information about a first beam (e.g., receive or transmit beam) for a first reference signal. For example, a UE can use a specific receive beam to receive a reference downlink reference signal (e.g., a synchronization signal block (SSB)) from a base station. The UE can then form a transmit beam for transmitting an uplink reference signal (e.g., a sounding reference signal (SRS)) to that base station based on the parameters of the receive beam.

[0054] It is important to note that, depending on the entity forming the "downlink" beam, the beam can be either a transmit beam or a receive beam. For example, if the base station is forming a downlink beam to transmit a reference signal to the UE, the downlink beam is a transmit beam. However, if the UE is forming a downlink beam, the downlink beam is a receive beam for receiving the downlink reference signal. Similarly, depending on the entity forming the "uplink" beam, the beam can be either a transmit beam or a receive beam. For example, if the base station is forming an uplink beam, the uplink beam is an uplink receive beam, while if the UE is forming an uplink beam, the uplink beam is an uplink transmit beam.

[0055] The electromagnetic spectrum is typically subdivided into various categories, bands, channels, etc., based on frequency / wavelength. In 5G NR, two initial operating bands have been designated as frequency ranges FR1 (410MHz to 7.125GHz) and FR2 (24.25GHz to 52.6GHz). It should be understood that although a portion of FR1 is greater than 6GHz, in various documents and articles, FR1 is often (interchangeably) referred to as the "sub-6GHz" band. A similar naming issue sometimes occurs with FR2, which is often (interchangeably) referred to as the "millimeter wave" band in documents and articles, although this differs from the designation used by the International Telecommunication Union.® Extremely high frequency (EHF) bands (30 GHz to 300 GHz) are designated as “millimeter wave” bands.

[0056] The frequencies between FR1 and FR2 are generally referred to as mid-band frequencies. Recent 5G NR studies have identified the operating bands used for these mid-band frequencies as the frequency range designation FR3 (7.125 GHz to 24.25 GHz). Bands falling within FR3 can inherit FR1 and / or FR2 characteristics, thus effectively extending the features of FR1 and / or FR2 to mid-band frequencies. Furthermore, higher frequency bands are currently being explored to extend 5G NR operation beyond 52.6 GHz. For example, three higher operating frequency bands have been identified as the frequency range designations FR4a or FR4-1 (52.6 GHz to 71 GHz), FR4 (52.6 GHz to 114.25 GHz), and FR5 (114.25 GHz to 300 GHz). Each of these higher frequency bands falls within the EHF band.

[0057] In light of the foregoing, unless otherwise specifically stated, it should be understood that, as used herein, the term "below 6 GHz" and the like can broadly refer to frequencies less than 6 GHz, within FR1, or including intermediate frequency band frequencies. Furthermore, unless otherwise specifically stated, it should be understood that, as used herein, the term "millimeter wave" and the like can broadly refer to frequencies that can include intermediate frequency band frequencies, within FR2, FR4, FR4-a or FR4-1 and / or FR5, or within the EHF band.

[0058] In multi-carrier systems such as 5G, one of the carrier frequencies is referred to as the "primary carrier," "anchor carrier," "primary serving cell," or "PCell," and the remaining carrier frequencies are referred to as "secondary carriers," "secondary serving cells," or "SCell." In carrier aggregation, the anchor carrier is the carrier operating on the primary frequency (e.g., FR1) used by UE 104 / 182 and the cell, where UE 104 / 182 performs an initial Radio Resource Control (RRC) connection establishment procedure or initiates an RRC connection re-establishment procedure. The primary carrier carries all common and UE-specific control channels and can be a carrier on a licensed frequency (however, this is not always the case). The secondary carrier is a carrier operating on a second frequency (e.g., FR2) that can be configured and used to provide additional radio resources once an RRC connection is established between UE 104 and the anchor carrier. In some cases, the secondary carrier can be a carrier on an unlicensed frequency. Secondary carriers may contain only necessary signaling information and signals. For example, since the primary uplink and primary downlink carriers are typically UE-specific, those UE-specific signaling information and signals may not exist in the secondary carrier. This means that different UEs 104 / 182 within a cell can have different downlink primary carriers. The same applies to the uplink primary carrier. The network can change the primary carrier of any UE 104 / 182 at any time. This is done, for example, to balance the load on different carriers. Since a "serving cell" (whether PCell or SCell) corresponds to the carrier frequency / component carrier through which a base station communicates, the terms "cell," "serving cell," "component carrier," and "carrier frequency" can be used interchangeably.

[0059] For example, still refer to Figure 1 One of the frequencies used by macro cell base station 102 can be an anchor carrier (or "PCell"), and the other frequencies used by macro cell base station 102 and / or mmW base station 180 can be secondary carriers ("SCell"). Simultaneous transmission and / or reception on multiple carriers allows UE 104 / 182 to significantly increase its data transmission and / or reception rates. For example, compared to the data rate obtained by a single 20MHz carrier, two aggregated 20MHz carriers in a multi-carrier system would theoretically result in a doubling of the data rate (i.e., 40MHz).

[0060] exist Figure 1 In the example, the UE shown (for simplicity, in) Figure 1Any UE (shown as a single UE 104) can receive signal 124 from one or more Earth-orbiting spacecraft (SV) 112 (e.g., satellites). In one aspect, SV 112 may be part of a satellite positioning system that allows UE 104 to use as an independent source of location information. Satellite positioning systems typically include a system of transmitters (e.g., SV 112) positioned such that a receiver (e.g., UE 104) can determine its location on or above the Earth based at least in part on positioning signals (e.g., signal 124) received from the transmitters. Such transmitters typically transmit signals marked with a set number of repeating pseudo-random noise (PN) codes. While typically located in SV 112, transmitters may sometimes be located at ground-based control stations, base stations 102, and / or other UEs 104. UE 104 may include one or more dedicated receivers specifically designed to receive signal 124 in order to derive geographic location information from SV 112.

[0061] In a satellite positioning system, the use of signal 124 can be enhanced by various satellite-based augmentation systems (SBAS), which may be associated with or otherwise made capable of being used with one or more global and / or regional navigation satellite systems. For example, SBAS may include augmentation systems that provide integrity information, differential correction, etc., such as Wide Area Augmentation System (WAAS), European Geostationary Navigation Overlap Service (EGNOS), Multifunctional Satellite Augmentation System (MSAS), GPS-assisted geographic augmentation navigation, or GPS and geographic augmentation navigation system (GAGAN). Therefore, as used herein, a satellite positioning system may include any combination of one or more global and / or regional navigation satellites associated with such one or more satellite positioning systems.

[0062] On one hand, SV 112 may additionally or alternatively be part of one or more non-terrestrial networks (NTNs). In an NTN, SV 112 connects to an earth station (also referred to as a ground station, NTN gateway, or gateway), which in turn connects to elements in the 5G network, such as the modified base station 102 (without a ground antenna) or network nodes in a 5GC. This element, in turn, provides access to other elements in the 5G network and ultimately to entities outside the 5G network, such as internet web servers and other user equipment. Thus, as a replacement or supplement to communication signals from the ground base station 102, UE 104 can receive communication signals (e.g., signal 124) from SV 112.

[0063] Leveraging the increased data rates and reduced latency of NR (Radio Frequency I / O), vehicle-to-everything (V2X) communication technology is being implemented to support Intelligent Transportation Systems (ITS) applications, such as wireless communication between vehicles (V2V), between vehicles and roadside infrastructure (V2I), and between vehicles and pedestrians (V2P). The goal is to enable vehicles to sense their surroundings and communicate that information to other vehicles, infrastructure, and personal mobile devices. This type of vehicle communication will achieve safety, mobility, and environmental improvements that current technologies cannot provide. Once fully realized, this technology is expected to reduce collisions involving undamaged vehicles by 80%.

[0064] Still referencing Figure 1 The wireless communication system 100 may include multiple V-UEs 160, which can communicate with base station 102 on communication link 120 using a Uu interface (i.e., the air interface between the UE and the base station). V-UEs 160 can also communicate directly with each other on wireless sidelink 162, with roadside unit (RSU) 164 (roadside access point) on wireless sidelink 166, or with sidelink-capable UE 104 on wireless sidelink 168 using a PC5 interface (i.e., the air interface between UEs with sidelink capability). A wireless sidelink (or simply "sidelink") is an adaptation of core cellular network (e.g., LTE, NR) standards that allows direct communication between two or more UEs without the need for communication through a base station. Sidelink communication can be unicast or multicast and can be used for device-to-device (D2D) media sharing, V2V communication, V2X communication (e.g., cellular V2X (cV2X) communication, enhanced V2X (eV2X) communication, emergency rescue applications, etc. One or more V-UEs in a group of V-UEs 160 utilizing sidelink communication may be within the geographical coverage area 110 of base station 102. Other V-UEs 160 in such a group may be outside the geographical coverage area 110 of base station 102, or may be unable to receive transmissions from base station 102 for other reasons. In some cases, groups of V-UEs 160 communicating via sidelink communication may utilize a one-to-many (1:M) system, where each V-UE 160 transmits to every other V-UE 160 in the group. In some cases, base station 102 facilitates the scheduling of resources for sidelink communication. In other cases, sidelink communication is performed between V-UEs 160 without involving base station 102.

[0065] On one hand, sidelinks 162, 166, and 168 can operate via a wireless communication medium of interest, which can be shared with other vehicles and / or infrastructure access points and other wireless communications between RATs. “Medium” can include one or more time, frequency, and / or space communication resources (e.g., covering one or more channels across one or more carriers) associated with wireless communication between one or more transmitter / receiver pairs.

[0066] On one hand, sidelinks 162, 166, and 168 can be cV2X links. First-generation cV2X has been standardized in LTE, and the next generation is expected to be defined in NR. cV2X is a cellular technology that also enables device-to-device communication. In the United States and Europe, cV2X is expected to operate in licensed ITS bands below 6 GHz. Other bands may be allocated in other countries. Thus, as a specific example, the medium of interest utilized by sidelinks 162, 166, and 168 may correspond to at least a portion of licensed ITS bands below 6 GHz. However, this disclosure is not limited to this band or cellular technology.

[0067] On one hand, sidelinks 162, 166, and 168 can be Dedicated Short-Range Communications (DSRC) links. DSRC is a one-way or two-way short-to-medium-range wireless communication protocol that uses the Vehicle Environment Wireless Access (WAVE) protocol (also known as IEEE 802.11p) for V2V, V2I, and V2P communications. IEEE 802.11p is an approved modification of the IEEE 802.11 standard and operates in the licensed ITS band of 5.9 GHz (5.85 GHz to 5.925 GHz) in the United States. In Europe, IEEE 802.11p operates in the ITS G5A band (5.875 GHz to 5.905 MHz). Other bands may be allocated in other countries. The V2V communications briefly described above occur on a secure channel, which in the United States is typically a 10 MHz channel dedicated to security purposes. The remainder of the DSRC band (total bandwidth of 75MHz) is intended for other services of interest to drivers, such as road rules, toll collection, parking automation, etc. Therefore, as a specific example, the media of interest utilized by side links 162, 166, and 168 may correspond to at least a portion of the licensed ITS band at 5.9GHz.

[0068] Alternatively, the medium of interest may correspond to at least a portion of unlicensed frequency bands shared among various RATs. While different licensed frequency bands have been reserved for certain communication systems (e.g., by government entities such as the U.S. Federal Communications Commission (FCC), these systems (particularly those employing small cell access points) have recently expanded their operations to unlicensed National Information Infrastructure (U-NII) bands used by wireless local area network (WLAN) technologies, most notably the IEEE 802.11x WLAN technology commonly referred to as "Wi-Fi"). Example systems of this type include various variants of CDMA, TDMA, FDMA, orthogonal FDMA (OFDMA), single-carrier FDMA (SC-FDMA), and so on.

[0069] Communication between V-UE 160 is referred to as V2V communication, communication between V-UE 160 and one or more RSUs 164 is referred to as V2I communication, and communication between V-UE 160 and one or more UEs 104 (where these UEs 104 are P-UEs) is referred to as V2P communication. V2V communication between V-UE 160 may include information such as the location, speed, acceleration, heading (e.g., instantaneous trajectory) and other vehicle data of V-UE 160. V2I information received at V-UE 160 from the one or more RSUs 164 may include, for example, road rules, parking automation information, etc. V2P communication between V-UE 160 and UE 104 may include information such as the location, speed, acceleration, and heading of V-UE 160, and the location, speed (e.g., in the case where UE 104 is carried by a cyclist), and heading of UE 104.

[0070] It should be noted that, although Figure 1 Only two UEs in the UE list are exemplified as V-UEs (V-UE 160), but any UE in the exemplified UEs (e.g., UE 104, 152, 182, 190) can be V-UEs. Furthermore, although only these V-UEs 160 and a single UE 104 have been exemplified as connected via a sidelink, Figure 1Any of the illustrated UEs, whether V-UE, P-UE, etc., may be capable of sidelink communication. Furthermore, although only UE 182 is described as capable of beamforming, any of the illustrated UEs (including V-UE 160) may be capable of beamforming. When V-UE 160 is capable of beamforming, it can beamform towards each other (i.e., towards other V-UEs 160), towards RSU 164, towards other UEs (e.g., UEs 104, 152, 182, 190), etc. Therefore, in some cases, V-UE 160 may utilize beamforming on sidelinks 162, 166, and 168.

[0071] The wireless communication system 100 may also include one or more UEs (such as UE 190) indirectly connected to one or more communication networks via one or more device-to-device (D2D) peer-to-peer (P2P) links. Figure 1 In one example, UE 190 has a D2D P2P link 192 with one of UEs 104 connected to one of the base stations 102 (e.g., UE 190 can indirectly obtain cellular connectivity through this D2D P2P link), and a D2D P2P link 194 with a WLANSTA 152 connected to a WLAN AP 150 (UE 190 can indirectly obtain WLAN-based Internet connectivity through this D2D P2P link). In one example, D2D P2P links 192 and 194 can utilize any known D2D RAT (such as LTE Direct (LTE-D), Wi-Fi Direct). ® ,Bluetooth ® (etc.) to support it. As another example, D2D P2P link 192 and D2D P2P link 194 can be side links, as described above with reference to side links 162, 166 and 168.

[0072] Figure 2AAn example wireless network architecture 200 is illustrated. For instance, the 5GC 210 (also referred to as the Next Generation Core (NGC)) can be functionally viewed as control plane (C-plane) functions 214 (e.g., UE registration, authentication, network access, gateway selection, etc.) and user plane (U-plane) functions 212 (e.g., UE gateway functions, access to data networks, IP routing, etc.), which work together to form the core network. The user plane interface (NG-U) 213 and the control plane interface (NG-C) 215 connect the gNB 222 to the 5GC 210, specifically to user plane functions 212 and control plane functions 214, respectively. In an additional configuration, the ng-eNB 224 can also connect to the 5GC 210 via the NG-C 215 to the control plane function 214 and the NG-U 213 to the user plane function 212. Furthermore, the ng-eNB 224 can communicate directly with the gNB 222 via a backhaul connection 223. In some configurations, the next-generation RAN (NG-RAN) 220 may have one or more gNBs 222, while other configurations include one or more of both ng-eNBs 224 and gNBs 222. Either or both of the gNBs 222 or ng-eNBs 224 can communicate with one or more UEs 204 (e.g., any of the UEs described herein).

[0073] Another optional aspect may include a location server 230 that can communicate with the 5GC 210 to provide location assistance to the UE 204. The location server 230 may be implemented as multiple separate servers (e.g., physically separate servers, different software modules on a single server, different software modules distributed across multiple physical servers, etc.), or alternatively, each may correspond to a single server. The location server 230 may be configured to support one or more location services for the UE 204 that can be connected to the location server 230 via the core network, the 5GC 210, and / or via the Internet (not illustrated). Furthermore, the location server 230 may be integrated into a component of the core network, or alternatively, may be located outside the core network (e.g., a third-party server, such as an original equipment manufacturer (OEM) server or a service server).

[0074] Figure 2B Another example wireless network architecture 240.5GC 260 is illustrated (which can be used with...). Figure 2AThe 5GC 210 (corresponding to 5GC 210) can be functionally considered as a control plane function provided by the Access and Mobility Management Function (AMF) 264 and a user plane function provided by the User Plane Function (UPF) 262, which work together to form the core network (i.e., 5GC 260). The functions of AMF 264 include: registration management, connection management, reachability management, mobility management, lawful interception, transmission of session management (SM) messages between one or more UEs 204 (e.g., any of the UEs described herein) and the Session Management Function (SMF) 266, a transparent proxy service for routing SM messages, access authentication and access authorization, transmission of short message service (SMS) messages between UE 204 and the Short Message Service Function (SMSF) (not shown), and Secure Anchoring Functionality (SEAF). AMF 264 also interacts with the Authentication Server Function (AUSF) (not shown) and UE 204 and receives an intermediate key established as a result of the UE 204's authentication process. In the case of UMTS (Universal Mobile Telecommunications System) Subscriber Identity Module (USIM) authentication, AMF 264 retrieves security material from the AMF. AMF 264 also includes Security Context Management (SCM). The SCM receives a key from the SEAF and uses this key to derive an access network-specific key. AMF 264 functionality also includes location service management for regulatory services, transmission of location service messages between UE 204 and Location Management Function (LMF) 270 (which acts as location server 230), transmission of location service messages between NG-RAN 220 and LMF 270, Evolved Packet System (EPS) bearer identifier allocation for EPS interoperability, and UE 204 mobility event notification. Furthermore, AMF 264 also supports non-3GPP... ® (Third Generation Partner Program) Access network functionality.

[0075] The functions of UPF 262 include: acting as an anchor point for intra-RAT / inter-RAT mobility (where applicable), acting as an external Protocol Data Unit (PDU) session point interconnecting to a data network (not shown), providing packet routing and forwarding, packet inspection, user plane policy rule enforcement (e.g., strobing, redirection, traffic steering), lawful eavesdropping (user plane collection), traffic usage reporting, quality of service (QoS) processing for the user plane (e.g., uplink / downlink rate enforcement, reflective QoS marking in the downlink), uplink traffic verification (Service Data Flow (SDF) to QoS flow mapping), transport-level packet marking in the uplink and downlink, downlink packet buffering and downlink data notification triggering, and delivering and forwarding one or more "end markers" to the source RAN node. UPF 262 can also support the delivery of location service messages between UE 204 and location servers (such as SLP 272) on the user plane.

[0076] The functions of SMF 266 include session management, UE Internet Protocol (IP) address allocation and management, selection and control of user plane functions, service orientation configuration at UPF 262 for routing services to the correct destination, partial control of policy enforcement and QoS, and downlink data notification. The interface through which SMF 266 communicates with AMF 264 is called the N11 interface.

[0077] Another optional aspect may include an LMF 270, which can communicate with the 5GC 260 to provide location assistance to the UE 204. The LMF 270 can be implemented as multiple separate servers (e.g., physically separate servers, different software modules on a single server, different software modules distributed across multiple physical servers, etc.), or alternatively, each can correspond to a single server. The LMF 270 can be configured to support one or more location services for the UE 204, which can connect to the LMF 270 via the core network, the 5GC 260, and / or via the Internet (not illustrated). SLP 272 can support similar functions to LMF 270, but while LMF 270 can communicate with AMF 264, NG-RAN 220, and UE 204 on the control plane (e.g., using interfaces and protocols designed to transmit signaling messages rather than voice or data), SLP 272 can communicate with UE 204 and external clients (e.g., third-party server 274) on the user plane (e.g., using protocols designed to carry voice and / or data, such as Transmit Control Protocol (TCP) and / or IP).

[0078] Another optional aspect may include a third-party server 274 that can communicate with LMF 270, SLP 272, 5GC 260 (e.g., via AMF 264 and / or UPF 262), NG-RAN 220, and / or UE 204 to obtain location information (e.g., location estimation) of UE 204. Therefore, in some cases, the third-party server 274 may be referred to as a Location Services (LCS) client or an external client. The third-party server 274 may be implemented as multiple separate servers (e.g., physically separate servers, different software modules on a single server, different software modules distributed across multiple physical servers, etc.), or alternatively, each may correspond to a single server.

[0079] User plane interface 263 and control plane interface 265 connect 5GC 260, and specifically connect UPF 262 and AMF 264 to one or more gNB 222 and / or ng-eNB 224 in NG-RAN 220. The interface between gNB 222 and / or ng-eNB 224 and AMF 264 is referred to as the "N2" interface, while the interface between gNB 222 and / or ng-eNB 224 and UPF 262 is referred to as the "N3" interface. The gNB 222 and / or ng-eNB 224 of NG-RAN 220 can communicate directly with each other via backhaul connection 223, referred to as the "Xn-C" interface. One or more of gNB 222 and / or ng-eNB 224 can communicate with one or more UEs 204 via a radio interface referred to as the "Uu" interface.

[0080] The functionality of the gNB 222 is divided among the gNB Central Unit (gNB-CU) 226, one or more gNB Distributed Units (gNB-DU) 228, and one or more gNB Radio Units (gNB-RU) 229. The gNB-CU 226 is a logical node that includes base station functions other than those specifically allocated to the gNB-DU 228, including user data delivery, mobility control, radio access network sharing, location, session management, etc. More specifically, the gNB-CU 226 typically hosts the Radio Resource Control (RRC), Serving Data Adaptation Protocol (SDAP), and Packet Data Convergence Protocol (PDCP) protocols of the gNB 222. The gNB-DU 228 is a logical node that typically hosts the Radio Link Control (RLC) and Media Access Control (MAC) layers of the gNB 222. Its operation is controlled by the gNB-CU 226. One gNB-DU 228 can support one or more cells, and a cell is supported by only one gNB-DU 228. The interface 232 between gNB-CU 226 and one or more gNB-DU 228 is referred to as the "F1" interface. The physical (PHY) layer functionality of gNB 222 is typically managed by one or more independent gNB-RU 229s, which perform functions such as power amplification and signal transmission / reception. The interface between gNB-DU 228 and gNB-RU 229 is referred to as the "Fx" interface. Therefore, UE 204 communicates with gNB-CU 226 via the RRC, SDAP, and PDCP layers, with gNB-DU 228 via the RLC and MAC layers, and with gNB-RU 229 via the PHY layer.

[0081] Autonomous and semi-autonomous driving safety technologies use a combination of hardware (sensors, cameras, and radar) and software to help vehicles identify certain safety risks so that they can warn the driver to take action (in the case of ADAS) or act autonomously (in the case of ADS) to avoid a collision. Vehicles equipped with ADAS or ADS include one or more camera sensors mounted on the vehicle that capture images of the scene in front of the vehicle, and possibly behind and to the sides. Radar systems can also be used to detect objects along the road and possibly behind and to the sides of the vehicle. Radar systems use RF waves to determine the range, direction, speed, and / or height of objects along the road. More specifically, a transmitter sends pulses of RF waves that bounce off any object in its path. The pulses reflected from the object return a small fraction of the energy of the RF waves to a receiver, which is typically located at the same location as the transmitter. Cameras and radars are typically oriented to capture their respective versions of the same scene.

[0082] Processors within vehicles (such as digital signal processors (DSPs)) analyze captured camera images and radar frames, attempting to identify objects within the captured scene. These objects can be other vehicles, pedestrians, road signs, objects on the road, etc. Radar systems provide reasonably accurate measurements of object distance and velocity under various weather conditions. However, radar systems typically lack sufficient resolution to identify the features of detected objects. Camera sensors, on the other hand, usually do provide sufficient resolution to identify object features. Cues about object shape and appearance extracted from captured images can provide sufficient characteristics for classifying different objects. Given the complementary properties of two sensors, data from both sensors can be combined (called "fusion") within a single system for improved performance.

[0083] Modern motor vehicles increasingly incorporate technologies that help drivers avoid drifting into adjacent lanes or making unsafe lane changes (e.g., Lane Departure Warning (LDW)), technologies that warn drivers of other vehicles behind them when a vehicle is reversing, or technologies that automatically brake if the vehicle in front of it suddenly stops or slows down (e.g., Forward Collision Warning (FCW)), and so on. The continued evolution of automotive technology aims to provide even greater safety benefits and ultimately deliver automated driving systems (ADS) capable of taking control of the entire driving task without user intervention.

[0084] There are six defined levels for achieving full automation. At Level 0, the human driver performs all driving. At Level 1, the Advanced Driver Assistance System (ADAS) on the vehicle may sometimes assist the human driver in steering or braking / acceleration, but not simultaneously. At Level 2, the ADAS on the vehicle can, in some situations, effectively control both steering and braking / acceleration simultaneously. The human driver must maintain full attention and perform the remaining driving tasks at all times. At Level 3, the ADAS on the vehicle can perform all aspects of driving tasks in certain situations. In these situations, the human driver must be ready to relinquish control at any time the ADAS requests it to. In all other situations, the human driver performs the driving tasks. At Level 4, the ADAS on the vehicle can perform all driving tasks and monitor the driving environment, essentially performing all driving in some situations. In these situations, human attention is not required. At Level 5, the ADAS on the vehicle can perform all driving in all situations. The human occupant is merely a passenger and is never involved in driving.

[0085] To further enhance ADAS and ADS systems, especially at Level 3 and higher, autonomous and semi-autonomous vehicles can utilize high-definition (HD) map datasets. These datasets contain significantly more detailed information and true-ground absolute accuracy than found in current conventional resources. Such HD maps provide accuracy within an absolute range of 7cm to 10cm, a highly detailed catalog of all road-related fixed physical assets, such as road lanes, road edges, shoulders, dividers, traffic signals, signs, paint markings, poles, and other data that aids in the safe navigation of autonomous / semi-autonomous vehicles on roads and at intersections. HD maps also provide electronic horizon prediction awareness, enabling autonomous / semi-autonomous vehicles to know what lies ahead.

[0086] It should be noted that autonomous or semi-autonomous vehicles can be, but do not have to be, V-UEs. Similarly, V-UEs can be, but do not have to be, autonomous or semi-autonomous vehicles. Autonomous or semi-autonomous vehicles are those equipped with ADAS or ADS. V-UEs are vehicles with cellular connectivity to 5G or other cellular networks. Autonomous or semi-autonomous vehicles that use or are able to use cellular technologies for positioning and / or navigation are V-UEs.

[0087] Now for reference Figure 3A An example is a V2X-capable vehicle 300 (referred to as a "self-driving vehicle" or "primary vehicle"), which includes a radar camera sensor module 320 located in the interior compartment behind a windshield 362 of the V2X-capable vehicle 300. The radar camera sensor module 320 includes a radar assembly configured to transmit radar signals through the windshield 362 within a horizontal coverage area 365 (shown by dashed lines) and to receive reflected radar signals reflected from any object within the horizontal coverage area 365. The radar camera sensor module 320 also includes a camera assembly for capturing images based on light waves seen and captured through the windshield 362 within the horizontal coverage area 360 (shown by dashed lines).

[0088] Although Figure 3A An example is illustrated where the radar and camera components are co-located within a shared housing, but as will be understood, these components can be separately housed in different locations within the V2X-capable vehicle 300. For example, the camera could be located as follows: Figure 3A As shown, the radar assembly can be located in the radiator grille or front bumper of a V2X-capable vehicle 300. Additionally, although... Figure 3A For example, the radar camera sensor module 320 is located behind the windshield 362, but it can alternatively be located in a roof-mounted sensor array or elsewhere. Furthermore, although Figure 3AOnly a single radar camera sensor module 320 is illustrated, but as will be understood, a V2X-capable vehicle 300 may have multiple radar camera sensor modules 320 pointing in different directions (to the side, front, rear, etc.). The various radar camera sensor modules 320 may be under the vehicle's "skin" (e.g., behind the windshield 362, door panels, bumpers, guardrails, etc.) or within a top-mounted sensor array.

[0089] The radar camera sensor module 320 can detect one or more (or none) objects relative to a vehicle 300 with V2X capability. Figure 3A In the example, the radar camera sensor module 320 can detect two objects, namely vehicles 370 and 380, within a horizontal coverage area 360 and 365. The radar camera sensor module 320 can estimate parameters of the detected objects, such as location, range, orientation, speed, size, and classification (e.g., vehicles, pedestrians, road signs, etc.). The radar camera sensor module 320 can be used onboard a V2X-capable vehicle 300 for automotive safety applications such as adaptive cruise control (ACC), forward collision warning (FCW), collision mitigation or avoidance via autonomous braking, low-speed collision warning (LDW), and the like.

[0090] Co-locating cameras and radar allows these components to share electronics and signal processing, particularly enabling early radar-camera data fusion. For example, radar and cameras can be integrated onto a single board. Joint radar-camera alignment techniques can be used to align both the radar and camera. However, implementing the techniques described in this paper does not require co-locating radar and cameras.

[0091] Figure 3B An onboard computer (OBC) 380 of a V2X-capable vehicle 300 is illustrated according to various aspects of this disclosure. In one aspect, the OBC 380 may be part of an ADAS or ADS. The OBC 380 may also be a V-UE of the V2X-capable vehicle 300. The OBC 380 includes a non-transitory computer-readable storage medium (i.e., memory 304) and one or more processors 306 communicating with the memory 304 via a data bus 308. The memory 304 includes one or more storage modules storing computer-readable instructions executable by the one or more processors 306 to perform the functions of the OBC 380 described herein. For example, the combination of one or more processors 306 with the memory 304 can implement various operations described herein.

[0092] One or more radar camera sensor modules 320 are coupled to OBC 380 (for simplicity, Figure 3B(Only one is shown in the image). In some aspects, the radar camera sensor module 320 includes at least one camera 312, at least one radar 314, and an optional light detection and ranging (LiDAR) sensor 316. The OBC 380 also includes one or more system interfaces 310 that connect one or more processors 306 to the radar camera sensor module 320 via a data bus 308, and optionally to other vehicle subsystems (not shown).

[0093] In at least some cases, the OBC 380 also includes one or more Wireless Wide Area Network (WWAN) transceivers 330 configured to communicate via one or more wireless communication networks (not shown) such as NR networks, LTE networks, and / or Global System for Mobile Communications (GSM) networks. The one or more WWAN transceivers 330 may be connected to one or more antennas (not shown) for communication with other network nodes (such as other V-UEs, pedestrian UEs, infrastructure access points, roadside units (RSUs), base stations (e.g., eNBs, gNBs), etc.) via at least one designated RAT (e.g., NR, LTE, GSM, etc.) through a wireless communication medium of interest (e.g., certain time / frequency resources in a specific spectrum). The one or more WWAN transceivers 330 may be configured in various ways to transmit and encode signals (e.g., messages, indications, information, etc.) according to the designated RAT and conversely, to receive and decode signals (e.g., messages, indications, information, pilots, etc.).

[0094] In at least some cases, the OBC 380 also includes one or more short-range wireless transceivers 340 (e.g., Wi-Fi transceivers, Bluetooth transceivers). ® Transceivers, etc.). One or more short-range wireless transceivers 340 may be connected to one or more antennas (not shown) for communicating with other network nodes (such as other V-UEs, pedestrian UEs, infrastructure access points, RSUs, etc.) via at least one designated RAT (e.g., cV2X), IEEE 802.11p (also known as Wireless Access for Vehicle Environments (WAVE)), Dedicated Short Range Communications (DSRC), etc.) through a wireless communication medium of interest. One or more short-range wireless transceivers 340 may be configured in various ways to transmit and encode signals (e.g., messages, indications, information, etc.) according to a designated RAT and conversely to receive and decode signals (e.g., messages, indications, information, pilots, etc.).

[0095] As used herein, a “transceiver” may include transmitter circuitry, receiver circuitry, or a combination thereof, but it is not necessary to provide both transmit and receive functionality in all designs. For example, in some designs, low-functionality receiver circuitry may be used to reduce costs when full communication is not necessary (e.g., simply providing a low-level sniffing receiver chip or similar circuitry).

[0096] In at least some cases, the OBC 380 also includes a Global Navigation Satellite System (GNSS) receiver 350. The GNSS receiver 350 may be connected to one or more antennas (not shown) for receiving satellite signals. The GNSS receiver 350 may include any suitable hardware and / or software for receiving and processing GNSS signals. The GNSS receiver 350 requests information and operation from other systems as appropriate and performs calculations necessary to determine the location of the vehicle 300 using measurements obtained through any suitable GNSS algorithm.

[0097] On one hand, the OBC 380 can utilize one or more WWAN transceivers 330 and / or one or more short-range wireless transceivers 340 to download one or more maps 302, which can then be stored in memory 304 and used for vehicle navigation. Map 302 can be one or more high-definition (HD) maps providing an accuracy of 7cm to 10cm in absolute range, a highly detailed list of all fixed entity assets associated with the road, such as road lanes, road edges, shoulders, dividing lines, traffic signals, signs, painted markings, utility poles, and other data useful for the safe navigation of the V2X-capable vehicle 300 on roads and at intersections. Map 302 can also provide electronic horizon prediction awareness, which enables the V2X-capable vehicle 300 to be aware of conditions ahead.

[0098] The V2X-capable vehicle 300 may include one or more sensors 322 that can be coupled to one or more processors 306 via one or more system interfaces 310. The one or more sensors 322 may provide components for sensing or detecting information related to the state and / or environment of the V2X-capable vehicle 300, such as speed, heading (e.g., compass heading), headlight status, fuel consumption, etc. For example, the one or more sensors 322 may include an odometer, speedometer, tachometer, accelerometer (e.g., microelectromechanical systems (MEMS) device), gyroscope, geomagnetic sensor (e.g., compass), altimeter (e.g., barometric altimeter), etc. Although shown as being located outside the OBC 380, some of these sensors 322 may be located on the OBC 380 and some may be located elsewhere within the V2X-capable vehicle 300.

[0099] The OBC 380 may also include a driving strategy component 318. The driving strategy component 318 may be part of or coupled to one or more processors 306, which, when executed, causes the OBC 380 to perform the functionality described herein. In other aspects, the driving strategy component 318 may be external to one or more processors 306 (e.g., part of a positioning processing system, integrated with another processing system, etc.). Alternatively, the driving strategy component 318 may be one or more memory modules stored in memory 304, which, when executed by one or more processors 306 (or a positioning processing system, another processing system, etc.), cause the OBC 380 to perform the functionality described herein. As a specific example, the driving strategy component 318 may include multiple positioning engines, a positioning engine aggregator, a sensor fusion module, and / or the like. Figure 3B Examples of possible locations for the driving strategy component 318 are shown. The driving strategy component may be part of, for example, memory 304, one or more processors 306, or any combination thereof, or may be a separate component.

[0100] On the one hand, camera 312 can capture the viewing area of ​​camera 312 (e.g., at a certain periodic rate) Figure 3A An image frame (also referred to herein as a camera frame) of a scene within a horizontal coverage area of ​​360° is illustrated. Similarly, radar 314 can capture the viewing area of ​​radar 314 (e.g., ...) at a certain periodic rate. Figure 3A Example: a radar frame representing a scene within a horizontal coverage area 365. The periodicity rates at which the camera 312 and radar 314 capture their respective frames can be the same or different. Each camera and radar frame can be timestamped. Therefore, in cases where the periodicity rates differ, the timestamp can be used to simultaneously or nearly simultaneously select the captured camera and radar frames for further processing (e.g., fusion).

[0101] For convenience, OBC 380 is... Figure 3B The diagram shows various components that can be configured according to the various examples described herein. However, it should be understood that the illustrated components may have different functionalities in different designs. Specifically, Figure 3B Various components are optional in alternative configurations, and various aspects, including configurations that may vary due to design choices, cost, equipment usage, or other considerations, are included. For the sake of brevity, examples of the various alternative configurations are not provided herein, but will be readily understood by those skilled in the art.

[0102] Figure 3B The components can be implemented in various ways. In some specific implementations, Figure 3BThe components may be implemented in one or more circuits, such as, for example, one or more processors and / or one or more ASICs (which may include one or more processors). Here, each circuit may use and / or combine at least one memory component for storing information or executable code used by the circuit to provide that functionality. For example, some or all of the functionality represented by blocks 302 to 350 may be implemented by the processor and memory components of the OBC 380 (e.g., by executing appropriate code and / or by appropriate configuration of the processor components). For simplicity, various operations, actions, and / or functions are described herein as being performed “by the UE,” “by the OBC,” or “by the vehicle.” However, as will be understood, such operations, actions, and / or functions may actually be performed by specific components or combinations of components of the OBC 380, such as one or more processors 306, one or more transceivers 330 and 340, memory 304, driving strategy component 318, etc.

[0103] In autonomous or semi-autonomous driving scenarios, the autonomous vehicle needs to make various driving decisions, such as when to change lanes (e.g., avoid obstacles, move to the exit lane, etc.), where to merge into traffic, whether to overtake another vehicle, and so on. These types of decisions are called "driving strategies" and can be executed by the OBC 380 (e.g., one or more processors 306, driving strategy components 318, memory 304, etc.) based on information from the radar camera sensor module 320 and / or sensor 322.

[0104] Figure 4A , Figure 4B and Figure 4C Several example components (represented by corresponding blocks) are illustrated, which may be incorporated into UE 402 (which may correspond to any of the UEs described herein, such as V2X-capable vehicle 300, OBC 380, etc.), base station 404 (which may correspond to any of the base stations described herein), and network entity 406 (which may correspond to or embody any of the network functions described herein (including location server 230 and LMF 270), or alternatively may be independent of... Figure 2A and Figure 2BThe NG-RAN 220 and / or 5GC 210 / 260 infrastructure (such as a private network) depicted herein supports the operations described herein. It should be understood that these components can be implemented in different specific implementations in different types of devices (e.g., in an ASIC, in a system-on-a-chip (SoC), etc.). The illustrated components can also be incorporated into other devices in the communication system. For example, other devices in the system may include components similar to those described as providing similar functionality. Furthermore, a given device may contain one or more of these components. For example, a device may include multiple transceiver components that enable the device to operate on multiple carriers and / or communicate via different technologies.

[0105] UE 402 and base station 404 each include one or more WWAN transceivers 410 and 450, which provide components (e.g., components for transmitting, components for receiving, components for measuring, components for tuning, components for blocking transmission, etc.) for communication via one or more wireless communication networks (not shown), such as NR networks, LTE networks, GSM networks, etc. WWAN transceivers 410 and 450 may each be connected to one or more antennas 416 and 456 for communication with other network nodes (such as other UEs, access points, base stations (e.g., eNB, gNB), etc.) via at least one designated RAT (e.g., NR, LTE, GSM, etc.) through a wireless communication medium of interest (e.g., a set of time / frequency resources in a specific spectrum). WWAN transceivers 410 and 450 can be configured in different ways to transmit and encode signals 418 and 458 (e.g., messages, indications, information, etc.) according to a specified RAT, and conversely, to receive and decode signals 418 and 458 (e.g., messages, indications, information, pilots, etc.). Specifically, WWAN transceivers 410 and 450 each include one or more transmitters 414 and 454 for transmitting and encoding signals 418 and 458, respectively, and one or more receivers 412 and 452 for receiving and decoding signals 418 and 458, respectively.

[0106] In at least some cases, UE 402 and base station 404 each further include one or more short-range radio transceivers 420 and 460, respectively. Short-range radio transceivers 420 and 460 may be connected to one or more antennas 426 and 466, respectively, and provide the capability to communicate over a wireless communication medium of interest via at least one designated RAT (e.g., Wi-Fi, LTE Direct, Bluetooth). ® ZIGBEE ® Z-WAVE ®The short-range transceiver 420 and 460 can be configured in different ways to transmit and encode signals 428 and 468 (e.g., messages, indications, information, etc.) according to a specified RAT, and conversely, to receive and decode signals 428 and 468 (e.g., messages, indications, information, pilots, etc.). Specifically, the short-range transceivers 420 and 460 each include one or more transmitters 424 and 464 for transmitting and encoding signals 428 and 468 respectively, and one or more receivers 422 and 462 for receiving and decoding signals 428 and 468 respectively. As specific examples, the short-range wireless transceivers 420 and 460 can be Wi-Fi transceivers, Bluetooth transceivers, etc. ® Transceiver, Zigbee ® and / or Z-WAVE ® Transceivers, NFC transceivers, UWB transceivers, or vehicle-to-vehicle (V2V) and / or vehicle-to-everything (V2X) transceivers.

[0107] In at least some cases, UE 402 and base station 404 also include satellite signal interfaces 430 and 470, each of which includes one or more satellite signal receivers 432 (e.g., GNSS receiver 350) and 472, and optionally may include one or more satellite signal transmitters 434 and 474. In some cases, base station 404 may be a terrestrial base station that can communicate with a spacecraft (e.g., spacecraft 112) via satellite signal interface 470. In other cases, base station 404 may be a spacecraft (or other non-terrestrial entity) that uses satellite signal interface 470 to communicate with terrestrial networks and / or other spacecraft.

[0108] Satellite signal receivers 432 and 472 may be connected to one or more antennas 436 and 476, respectively, and may provide components for receiving and / or measuring satellite positioning / communication signals 438 and 478, respectively. When satellite signal receivers 432 and 472 are satellite positioning system receivers, satellite positioning / communication signals 438 and 478 may be Global Positioning System (GPS) signals, Global Navigation Satellite System (GLONASS) signals, Galileo signals, BeiDou signals, Indian Regional Navigation Satellite System (NAVIC), Quasi-Zenith Satellite System (QZSS) signals, etc. When satellite signal receivers 432 and 472 are non-terrestrial network (NTN) receivers, satellite positioning / communication signals 438 and 478 may be communication signals originating from a 5G network (e.g., carrying control and / or user data). Satellite signal receivers 432 and 472 may include any suitable hardware and / or software for receiving and processing satellite positioning / communication signals 438 and 478, respectively. Satellite signal receivers 432 and 472 may request appropriate information and operations from other systems, and in at least some cases, use measurements obtained by any suitable satellite positioning system algorithm to perform calculations to determine the locations of UE 402 and base station 404, respectively.

[0109] Optional satellite signal transmitters 434 and 474 (when present) can be connected to one or more antennas 436 and 476, respectively, and can be provided with components for transmitting satellite positioning / communication signals 438 and 478, respectively. When satellite signal transmitter 474 is a satellite positioning system transmitter, the satellite positioning / communication signal 478 can be a GPS signal, GLONASS signal, etc. ® Signals include Galileo signals, BeiDou signals, NAVIC signals, and QZSS signals. When satellite signal transmitters 434 and 474 are NTN transmitters, satellite positioning / communication signals 438 and 478 can be communication signals originating from a 5G network (e.g., carrying control and / or user data). Satellite signal transmitters 434 and 474 can include any suitable hardware and / or software for transmitting satellite positioning / communication signals 438 and 478, respectively. Satellite signal transmitters 434 and 474 can request appropriate information and operations from other systems.

[0110] Base station 404 and network entity 406 each include one or more network transceivers 480 and 490, which provide components (e.g., transmitting components, receiving components, etc.) for communicating with other network entities (e.g., other base stations 404, other network entities 406). For example, base station 404 may use one or more network transceivers 480 to communicate with other base stations 404 or network entities 406 via one or more wired or wireless backhaul links. Similarly, network entity 406 may use one or more network transceivers 490 to communicate with one or more base stations 404 via one or more wired or wireless backhaul links, or to communicate with other network entities 406 via one or more wired or wireless core network interfaces.

[0111] Transceivers can be configured to communicate via wired or wireless links. A transceiver (whether wired or wireless) includes transmitter circuitry (e.g., transmitters 414, 424, 454, 464) and receiver circuitry (e.g., receivers 412, 422, 452, 462). In some embodiments, the transceiver may be an integrated device (e.g., implementing transmitter and receiver circuitry in a single device), in some embodiments it may include separate transmitter and receiver circuitry, or in other embodiments it may be implemented in a different manner. The transmitter and receiver circuitry of a wired transceiver (e.g., network transceivers 480 and 490 in some embodiments) may be coupled to one or more wired network interface ports. Wireless transmitter circuitry (e.g., transmitters 414, 424, 454, 464) may include or be coupled to multiple antennas (e.g., antennas 416, 426, 456, 466), such as an antenna array, which allows the corresponding device (e.g., UE 402, base station 404) to perform transmit "beamforming," as described herein. Similarly, wireless receiver circuitry (e.g., receivers 412, 422, 452, 462) may include or be coupled to multiple antennas (e.g., antennas 416, 426, 456, 466), such as an antenna array, which allows the corresponding device (e.g., UE 402, base station 404) to perform receive beamforming, as described herein. In one aspect, the transmitter and receiver circuitry may share the same multiple antennas (e.g., antennas 416, 426, 456, 466), such that the corresponding device may perform only receive or only transmit at a given time, rather than both receive and transmit simultaneously. Wireless transceivers (e.g., WWAN transceivers 410 and 450, short-range wireless transceivers 420 and 460) may also include network listening modules (NLMs) for performing various measurements.

[0112] As used herein, various wireless transceivers (e.g., transceivers 410, 420, 450, and 460 in some specific embodiments, and network transceivers 480 and 490) and wired transceivers (e.g., network transceivers 480 and 490 in some specific embodiments) can generally be characterized as "transceiver," "at least one transceiver," or "one or more transceivers." Therefore, whether a particular transceiver is a wired or wireless transceiver can be inferred from the type of communication performed. For example, backhaul communication between network devices or servers typically involves signaling via a wired transceiver, while wireless communication between a UE (e.g., UE 402) and a base station (e.g., base station 404) will typically involve signaling via a wireless transceiver.

[0113] UE 402, base station 404, and network entity 406 also include other components that can be used in conjunction with the operations disclosed herein. UE 402, base station 404, and network entity 406 each include one or more processors 442, 484, and 494 for providing functionality related to, for example, wireless communication, and for providing other processing functionality. Thus, processors 442, 484, and 494 may provide components for processing, such as components for determination, components for calculation, components for receiving, components for transmitting, components for indicating, etc. In one aspect, processors 442, 484, and 494 may include, for example, one or more general-purpose processors, multi-core processors, central processing units (CPUs), ASICs, digital signal processors (DSPs), field-programmable gate arrays (FPGAs), other programmable logic devices or processing circuits, or various combinations thereof.

[0114] UE 402, base station 404, and network entity 406 each include memory circuitry implementing memories 440, 486, and 496 (e.g., each including a memory device) for maintaining information (e.g., information indicating reserved resources, thresholds, parameters, etc.). Therefore, memories 440, 486, and 496 can provide components for storage, for capture, for maintenance, etc. In some cases, UE 402, base station 404, and network entity 406 may each include driving strategy components 448 (which may correspond to driving strategy component 318), 488, and 498. Driving strategy components 448, 488, and 498 may be components of processors 442, 484, and 494, or hardware circuitry respectively coupled to these processors, which, when executed, cause UE 402, base station 404, and network entity 406 to perform the functionality described herein. In other respects, driving strategy components 448, 488, and 498 may be external to processors 442, 484, and 494 (e.g., components of a modem processing system, integrated with another processing system, etc.). Alternatively, driving strategy components 448, 488, and 498 may be memory modules stored in memories 440, 486, and 496, respectively, which, when executed by processors 442, 484, and 494 (or a modem processing system, another processing system, etc.), cause UE 402, base station 404, and network entity 406 to perform the functionality described herein. Figure 4A Examples of possible locations for the driving strategy component 448 are shown. The driving strategy component may be, for example, one or more WWAN transceivers 410, memory 440, one or more processors 442, or any combination thereof, or may be a separate component. Figure 4B Examples of possible locations for the driving strategy component 488 are shown. The driving strategy component may be a component such as one or more WWAN transceivers 450, memory 486, one or more processors 484, or any combination thereof, or it may be a separate component. Figure 4C Examples of possible locations for the driving strategy component 498 are shown. The driving strategy component may be, for example, one or more network transceivers 490, memory 496, one or more processors 494, or any combination thereof, or may be a separate component.

[0115] UE 402 may include one or more sensors 444 coupled to one or more processors 442 to provide components for sensing or detecting motion and / or orientation information independent of motion data derived from signals received by one or more WWAN transceivers 410, one or more short-range wireless transceivers 420, and / or satellite signal interfaces 430. By way of example, sensor 444 may include accelerometers (e.g., microelectromechanical systems (MEMS) devices), gyroscopes, geomagnetic sensors (e.g., compasses), altimeters (e.g., barometric altimeters), and / or any other type of motion detection sensor. Furthermore, sensor 444 may include multiple different types of devices and combine their outputs to provide motion information. For example, sensor 444 may use a combination of multi-axis accelerometers and orientation sensors to provide the ability to calculate positioning in two-dimensional (2D) and / or three-dimensional (3D) coordinate systems.

[0116] In addition, UE 402 includes a user interface 446 that provides components for providing instructions to a user (e.g., audible and / or visual instructions) and / or for receiving user input (e.g., when the user actuates a sensing device such as a keypad, touchscreen, microphone, etc.). Although not shown, base station 404 and network entity 406 may also include user interfaces.

[0117] Referring more specifically to one or more processors 484, in the downlink, IP packets from network entity 406 can be provided to processor 484. One or more processors 484 can implement functionality for the RRC layer, Packet Data Convergence Protocol (PDCP) layer, Radio Link Control (RLC) layer, and Media Access Control (MAC) layer. One or more processors 484 may provide: RRC layer functionality associated with broadcasting system information (e.g., Master Information Block (MIB), System Information Block (SIB)), RRC connection control (e.g., RRC connection paging, RRC connection establishment, RRC connection modification, and RRC connection release), inter-RAT mobility, and measurement configuration for UE measurement reporting; PDCP layer functionality associated with header compression / decompression, security (encryption, decryption, integrity protection, integrity verification), and handover support functions; RLC layer functionality associated with the delivery of upper-layer PDUs, error correction via Automatic Repeat Request (ARQ), concatenation, segmentation, and reassembly of RLC Service Data Units (SDUs), resegmentation of RLC data PDUs, and reordering of RLC data PDUs; and MAC layer functionality associated with mapping between logical channels and transport channels, scheduling information reporting, error correction, priority handling, and logical channel priority ordering.

[0118] Transmitter 454 and receiver 452 implement Layer 1 (L1) functionality associated with various signal processing functions. Layer 1, including the physical (PHY) layer, may include: error detection on the transport channel, forward error correction (FEC) decoding / decoding of the transport channel, interleaving, rate matching, mapping to the physical channel, modulation / demodulation of the physical channel, and MIMO antenna processing. Transmitter 454 processes the mapping to the signal constellation based on various modulation schemes (e.g., binary phase shift keying (BPSK), quadrature phase shift keying (QPSK), M-phase shift keying (M-PSK), M-quadrature amplitude modulation (M-QAM)). The decoded and modulated symbols can then be divided into parallel streams. Each stream can then be mapped to orthogonal frequency division multiplexing (OFDM) subcarriers, multiplexed with a reference signal (e.g., pilot) in the time and / or frequency domains, and then combined using inverse fast Fourier transform (IFFT) to produce a physical channel carrying a time-domain OFDM symbol stream. The OFDM symbol stream is spatially pre-decoded to generate multiple spatial streams. Channel estimates from a channel estimator can be used to determine the decoding and modulation scheme, as well as for spatial processing. These channel estimates can be derived from a reference signal transmitted by UE 402 and / or channel condition feedback. Each spatial stream can then be provided to one or more different antennas 456. Transmitter 454 can use the corresponding spatial stream to modulate an RF carrier for transmission.

[0119] At UE 402, receiver 412 receives signals via its corresponding antenna 416. Receiver 412 recovers the information modulated onto the RF carrier and provides this information to one or more processors 442. Transmitter 414 and receiver 412 implement Layer 1 functionality associated with various signal processing functions. Receiver 412 can perform spatial processing on the information to recover any spatial streams destined for UE 402. If multiple spatial streams are destined for UE 402, they can be combined by receiver 412 into a single OFDM symbol stream. Receiver 412 then uses a Fast Fourier Transform (FFT) to transform the OFDM symbol stream from the time domain to the frequency domain. The frequency domain signal includes a separate OFDM symbol stream for each subcarrier of the OFDM signal. The symbols on each subcarrier, along with the reference signal, are recovered and demodulated by determining the most probable signal constellation points transmitted by base station 404. These soft decisions can be based on channel estimates calculated by a channel estimator. The soft decisions are then decoded and deinterleaved to recover the data and control signals originally transmitted by base station 404 on the physical channel. Then, data and control signals are provided to one or more processors 442, which implement layer 3 (L3) and layer 2 (L2) functionality.

[0120] In the downlink, one or more processors 442 provide demultiplexing, packet reassembly, decryption, header decompression, and control signal processing between the transport and logical channels to recover IP packets from the core network. One or more processors 442 are also responsible for error detection.

[0121] Similar to the functionality described in conjunction with downlink transmissions performed by base station 404, one or more processors 442 provide: RRC layer functionality associated with system information (e.g., MIB, SIB) acquisition, RRC connectivity, and measurement reporting; PDCP layer functionality associated with header compression / decompression and security (encryption, decryption, integrity protection, integrity verification); RLC layer functionality associated with the delivery of upper-layer PDUs, error correction via ARQ, concatenation, segmentation, and reassembly of RLC SDUs, resegmentation of RLC data PDUs, and reordering of RLC data PDUs; and MAC layer functionality associated with mapping between logical channels and transport channels, multiplexing of MAC SDUs onto transport blocks (TBs), demultiplexing of MAC SDUs from TBs, scheduling information reporting, error correction via Hybrid Automatic Repeat Request (HARQ), priority handling, and logical channel priority ordering.

[0122] The channel estimate derived by the channel estimator from the reference signal or feedback transmitted by the base station 404 can be used by the transmitter 414 to select an appropriate decoding and modulation scheme and facilitate spatial processing. The spatial stream generated by the transmitter 414 can be provided to different antennas 416. The transmitter 414 can use the corresponding spatial stream to modulate the RF carrier for transmission.

[0123] Uplink transmissions are processed at base station 404 in a manner similar to that described in conjunction with the receiver function at UE 402. Receiver 452 receives signals via its corresponding antenna 456. Receiver 452 recovers the information modulated onto the RF carrier and provides this information to one or more processors 484.

[0124] In the uplink, one or more processors 484 provide demultiplexing, packet reassembly, decryption, header decompression, and control signal processing between the transport channel and the logical channel to recover IP packets from UE 402. IP packets from one or more processors 484 can be provided to the core network. One or more processors 484 are also responsible for error detection.

[0125] For convenience, UE 402, base station 404 and / or network entity 406 are in Figure 4A , Figure 4B and Figure 4CThe document is shown as including various components that can be configured according to the various examples described herein. However, it should be understood that the illustrated components may have different functionalities in different designs. In particular, Figure 4A to Figure 4C Various components are optional in alternative configurations, and various aspects include configurations that can vary due to design choices, cost, equipment usage, or other considerations. For example, in Figure 4A In certain cases, specific implementations of UE 402 may omit WWAN transceiver 410 (e.g., wearable devices, tablets, personal computers (PCs), or laptops may have Wi-Fi and / or Bluetooth). ® (e.g., cellular only), or the short-range wireless transceiver 420 can be omitted (e.g., cellular only), or the satellite signal interface 430 can be omitted, or the sensor 444 can be omitted, etc. For example, in Figure 4B In certain cases, specific implementations of base station 404 may omit WWAN transceiver 450 (e.g., a Wi-Fi "hotspot" access point without cellular capabilities), or short-range wireless transceiver 460 (e.g., cellular only), or satellite signal interface 470, etc. For the sake of brevity, examples of various alternative configurations are not provided herein, but will be readily understood by those skilled in the art.

[0126] Various components of UE 402, base station 404, and network entity 406 can be communicatively coupled to each other via data buses 408, 482, and 492, respectively. In one aspect, data buses 408, 482, and 492 can form or be part of the communication interfaces of UE 402, base station 404, and network entity 406, respectively. For example, in cases where different logical entities are embodied in the same device (e.g., gNB and location server functionality integrated into the same base station 404), data buses 408, 482, and 492 can provide communication between these different logical entities.

[0127] Figure 4A , Figure 4B and Figure 4C The components can be implemented in various ways. In some specific implementations, Figure 4A , Figure 4B and Figure 4CThe components can be implemented in one or more circuits, such as, for example, one or more processors and / or one or more ASICs (which may include one or more processors). Here, each circuit may use and / or combine at least one memory component for storing information or executable code used by the circuit to provide that functionality. For example, some or all of the functionalities represented by blocks 410 to 446 may be implemented by the processor and memory components of UE 402 (e.g., by executing appropriate code and / or by appropriate configuration of the processor components). Similarly, some or all of the functionalities represented by blocks 450 to 488 may be implemented by the processor and memory components of base station 404 (e.g., by executing appropriate code and / or by appropriate configuration of the processor components). Moreover, some or all of the functionalities represented by blocks 490 to 498 may be implemented by the processor and memory components of network entity 406 (e.g., by executing appropriate code and / or by appropriate configuration of the processor components). For simplicity, various operations, actions, and / or functions are described herein as being performed "by the UE," "by the base station," "by the network entity," etc. However, as will be understood, such operations, actions, and / or functions may actually be performed by specific components or combinations of components of the UE 402, base station 404, network entity 406, etc., such as: processors 442, 484, 494; transceivers 410, 420, 450, and 460; memories 440, 486, and 496; driving strategy components 448, 488, and 498, etc.

[0128] In some designs, network entity 406 may be implemented as a core network component. In other designs, network entity 406 may operate differently from the network operator or cellular network infrastructure (e.g., NG RAN 220 and / or 5GC 210 / 260). For example, network entity 406 may be a component of a private network that can be configured to communicate with UE 402 via base station 404 or independently of base station 404 (e.g., via a non-cellular communication link such as Wi-Fi).

[0129] Driving strategy involves trajectory prediction and route planning functionality. Trajectory prediction follows a data-driven approach that incorporates hazard light status information, brake light status information, and trajectory history of other vehicles (referred to as "agents") around the self-driving vehicle, as well as map geometry (e.g., from map 302). Graph-based neural networks learn multi-agent interactions, while the weighted multimodal distribution of trajectories represents the uncertainty of agent intentions and movements. Randomized predicted trajectories are used for tree search and dynamic programming optimizers to achieve risk-minimizing self-driving maneuvers. It should be noted that tree search is only one method; trajectory prediction can also be performed using graph-based neural networks, where the weights of the neural network can be updated to adjust which trajectories / paths remain feasible.

[0130] Route planning attempts to understand the probabilistic evolution of the world by exploring a belief space. Self-driving actions are defined by predicting inputs to generate possible trajectories and agent actions. Route planning effectively prunes the search space (e.g., a search tree) and evaluates the risks and rewards of candidate trajectories. The output is a coarse reference trajectory along with the corresponding world beliefs and related semantics.

[0131] It should be noted that a driving trajectory is not necessarily a single driving maneuver (e.g., changing lanes, braking, merging, etc.), but rather a driving path that can be taken over the next few seconds to minutes. Therefore, a driving trajectory may include one or more planned driving maneuvers over a time period of several seconds to minutes.

[0132] Figure 5 This is a diagram 500 illustrating an example driving strategy pipeline according to various aspects of this disclosure. For example... Figure 5 As shown, at the advanced level, sensing and perception information (e.g., from camera 312, radar 314, lidar sensor 316, sensor 322) is fed into the Real World Model (RWM) block, which outputs map data (e.g., from map 302), object detection results (e.g., both fixed and moving objects), trajectory predictions of detected moving objects, and vehicle positions to the lane-level planner block, the global trajectory search block, and the local trajectory optimization block.

[0133] The lane-level planner module obtains at least map data and driving objectives (e.g., lane changing, merging, overtaking, etc.) from the RWM block and outputs the desired route plan [r] and lane instructions from the advanced global trajectory search block. The global trajectory search block generates a set of coarse reference trajectories (denoted as t_r) and a set of search and semantic parameters s_r based on the desired route plan [r] and information from the RWM block. The global trajectory search block outputs t_r and s_r to the local trajectory optimization block, which optimizes the local reaction trajectory and the set of coarse reference trajectories t_r based on information from the RWM block to determine a set of optimized trajectories [t_o].

[0134] The arbitration block (e.g., within a local trajectory optimization block) selects the minimum-cost candidate trajectory from the set of optimized trajectories [t_o] received from the local trajectory optimization block. The arbitration block will select the minimum cost candidate trajectory. The output is sent to a safety verification block (e.g., within a local trajectory optimization block), which verifies the minimum cost candidate trajectory. The safety of the candidate trajectory is ensured, and if it is safe, the candidate trajectory is selected. As the final "good luck" trajectory Output to the lateral control block and the trajectory The speed output is sent to the longitudinal control block. Based on these inputs, the lateral and longitudinal control blocks output steering, throttle, and braking control signals to their respective vehicle systems.

[0135] Figure 6 This is a diagram 600 illustrating an example driving strategy prediction and stochastic programming scenario according to various aspects of this disclosure. For example... Figure 6 As shown, a vehicle traveling on a three-lane highway intends to change lanes. Furthermore, there is traffic to the left of the vehicle, traffic in the same lane ahead of the vehicle, and traffic merging onto the highway from the left. The traffic in front of the vehicle is approaching a road hazard and needs to brake or change lanes to avoid it. Additionally, as traffic merges onto the highway, the vehicle to the left of the vehicle may need to change lanes. The driving strategy for this vehicle needs to consider all these possibilities. However, this is computationally expensive; therefore, reducing this burden would be beneficial.

[0136] Figure 7A and Figure 7BVarious scenarios that a driving strategy engine of a self-driving vehicle may encounter when performing autonomous or semi-autonomous driving maneuvers, according to various aspects of this disclosure, are illustrated. Specifically, Figure 710 illustrates an example overtaking scenario where a vehicle in front of the self-driving vehicle switches to the same lane as the self-driving vehicle. Figure 720 illustrates an example lane-changing scenario where the self-driving vehicle switches to a different lane (in front of another vehicle). Figure 730 illustrates an example merging scenario where another vehicle merges from around an obstacle into the same lane as the self-driving vehicle. Figure 740 illustrates an example stop sign scenario where the self-driving vehicle has stopped at a four-way intersection with two other vehicles. Figure 750 illustrates an example traffic light scenario where the self-driving vehicle intends to turn left through an intersection.

[0137] Figure 8 This is an illustration 800 showing the trajectory generated in an example driving scenario based on various aspects of this disclosure. For example... Figure 8 As shown, at each depth ahead of the self-driving vehicle (e.g., corresponding to a future time or distance), there exists a set of one or more macro-actions, each macro-action corresponding to a portion / segment / length of a road lane in which the self-driving vehicle can be located at that depth. Each macro-action is associated with a set of one or more nodes (exemplified on the other side of the self-driving vehicle's macro-action) indicating where the self-driving vehicle can be located within the macro-action (lane). Each node is connected by a path / trajectory from one macro-action to another. It can be seen that the possibilities are rapidly expanding.

[0138] Monte Carlo Tree Search (MCTS) can be used to focus search computations on the most promising subtrees (possible trajectories), particularly those that minimize risk while maximizing comfort, progress, etc. Furthermore, macro-action grouping can improve efficiency by focusing on the most valuable actions (e.g., changing lanes left, staying in the current lane, etc.). The cost function can be learned from data using supervised learning or inverse reinforcement learning (IRL) and can be scaled to risk-averse behavior planning under uncertainty. Monte Carlo Tree Search is also suitable for parallel acceleration of multiple roots, subtrees, and leaves.

[0139] Note that Monte Carlo tree search may not build a complete tree, such as... Figure 8 As shown. The complete tree will be O(b^d), where b is the branching factor and d is the depth. In contrast, Monte Carlo Tree Search has a fixed computational budget (such as node counting) and distributes the expansions of these nodes to more promising regions through an exploration and exploitation strategy. Monte Carlo Tree Search is also an "on-the-fly" planning algorithm because the most promising sequence of actions discovered so far can be generated at any time, but the solution is continuously refined as the budget allows.

[0140] Lateral branching is computationally more expensive than longitudinal branching (acceleration actions of the self-driving vehicle) because the driving strategy engine typically has to consider more surrounding traffic. This is primarily due to the need for collision checks over a wider space. For example, currently, longitudinal branching can be performed at approximately 5 Hz and 10,000 to 15,000 nodes in the tree, while lane changes and lateral offsets can be performed at approximately 2 Hz and far fewer nodes (e.g., approximately 100).

[0141] In some cases, sensing and perception data (e.g., from camera 312, radar 314, lidar sensor 316, sensor 322) may not be available to the driving strategy engine, or may provide a sensing range shorter than that of V2X communication. For example, dense fog may obscure any image data captured by camera 412, or obstacles may block the field of view of camera 412, radar 414, or lidar sensor 416, making it impossible for the autonomous vehicle to use its perception sensors to sense more than one or two other vehicles in the vicinity (if any). In such cases, V2X communication may be the only available perception input, or at least provide information about vehicles located at a distance greater than that detectable by the autonomous vehicle's perception sensors. Therefore, this disclosure provides techniques for leveraging different types of V2X messages to augment and even, where necessary, replace sensing and perception data. More specifically, the messages conveyed by V2X messages can be used to prune (e.g., remove or deweight) possible route trajectories.

[0142] As a primary use case, V2X messages can be Basic Safety Messages (BSMs). BSMs include the sender's location and motion status, but do not provide information about the sender's intentions to maneuver the vehicle. In other words, BSMs include the vehicle's instantaneous location, speed, and heading, but do not indicate whether the vehicle intends to turn, change lanes, merge, etc.

[0143] Figure 9 This is illustration 900 illustrating an example driving scenario according to various aspects of this disclosure, where the BSM can be used to trim possible route trajectories. (See diagram 900.) Figure 9 As shown, the autonomous vehicle is calculating its trajectory around the vehicle at depth 2 (e.g., overtaking trajectory). However, in Figure 9In the example, the autonomous vehicle cannot see the second V2X-capable vehicle (labeled "A") ahead of the vehicle at depth 3 in the same lane. Therefore, depth 3-C (the position of vehicle A) is considered a feasible option by the autonomous vehicle's driving strategy. The potential consequences of this problem include wasted computational resources because the trajectory calculated by the driving strategy is infeasible. Furthermore, this problem increases the burden on the computational system because the driving strategy needs to calculate a new trajectory when it is later discovered / determined that depth 3-C is not a feasible option (e.g., when the autonomous vehicle reaches depth 2).

[0144] It is important to note that a "feasible" trajectory is a path that the self-driving vehicle can drive / follow without colliding with another vehicle or obstacle. A feasible trajectory is feasible at the time of calculation, but as will be understood, the feasibility of a trajectory may change at a later point in time. For example, while another vehicle is following a selected feasible trajectory, it may overtake the self-driving vehicle, forcing the self-driving vehicle to update its current trajectory or find a new one.

[0145] Due to the type of algorithm used to calculate the trajectory, such additional trajectory computation can be particularly cumbersome / inefficient. For example, in Monte Carlo tree search, the algorithm balances "exploration" with "exploitation" to find a good / acceptable trajectory solution. If vehicle A is not visible, the system will have a flawed understanding of the world and may "exploit" the vicinity of vehicle A (i.e., depth 3-C) because the system perceives that area as usable. Therefore, an unmodeled agent (or more formally, an inaccurate distribution) may cause the search to fail by actually focusing on and / or exploiting points that should be avoided.

[0146] V2X messaging can be used to solve this problem by providing knowledge about vehicle A. Specifically, since vehicle A has V2X capability, it broadcasts its BSM to other nearby V2X-capable vehicles (including its own vehicle). Because the BSM includes the location of the sending vehicle, the own vehicle can now "see" that vehicle A is located at depth 3-C.

[0147] The BSM from vehicle A (and any other vehicles that were not originally visible to the self-driving vehicle) can help the self-driving vehicle's driving strategy by trimming infeasible (e.g., depth 3-C) trajectories and / or nodes (trimming nodes, trimming trajectories through those nodes) to refine the trajectory tree. Therefore, in Figure 9In the example, the BSM of vehicle A helps to remove / prune / reweight depths 3-C and 4-C from possible trajectories / nodes. Using BSM to prune trajectories / nodes helps driving policies achieve higher performance. For example, driving policies can refocus trajectory and / or node assignments on depths 3-A and 3-B, which are truly promising search areas.

[0148] As an example, for Monte Carlo Tree Search, the complexity of building a complete tree (or subtree) is O(b^d), where b is the branching factor and d is the depth. However, the Monte Carlo Tree Search algorithm does not build a complete tree; instead, it has a fixed computational budget (e.g., a certain number of nodes) and uses an online "explore" and "exploit" strategy to determine where to spend that budget. Therefore, while pruning (e.g., removing, reducing weight, lowering weight) subtrees at depth 3-C does not necessarily save overall computation time, it does correctly refocus the remaining node budget on truly promising subtrees. For example, if a subtree at depth 3-C yields a high reward before receiving the BSM from vehicle A, but there are still multiple consecutive paths to explore, the remaining node budget might be exhausted if only searching the subtree at depth 3-C. However, after pruning the subtree at depth 3-C, this node budget will instead be allocated elsewhere. There are two ways to think about this effect. First, fewer nodes might be needed to find the "best" trajectory within the search tree, otherwise the search tree would include subtrees at depth 3-C. For example, building a tree with 5000 nodes, deleting / pruning / reducing the weight of a 3-C subtree containing 1000 nodes, and finding the optimal trajectory among the remaining 4000 nodes, equivalence can be found with only 4000 nodes. Secondly, using the same node budget, it is more likely to find a more optimal path. For example, with the same 5000-node budget, by pruning invalid subtrees (e.g., subtrees at depth 3-C), the optimality of the solution is improved by X%.

[0149] As a second use case, V2X messages can be collectively aware messages (CPM). Figure 10 This is a diagram 1000 illustrating an example driving scenario according to various aspects of this disclosure, where CPM can be used to trim possible route trajectories. For example... Figure 10 As shown, the autonomous vehicle is calculating the trajectory (e.g., overtaking trajectory) around another V2X-capable vehicle (denoted as "B") in the same lane at depth 2. However, in Figure 10 In the example, the autonomous vehicle cannot see a non-V2X-capable vehicle (represented as "A") in front of vehicle B in the same lane. Therefore, depth 3-C (the position of vehicle A) is considered a feasible option by the autonomous vehicle's driving strategy.

[0150] CPM provides information about the presence and status of any objects sensed by the transmitting vehicle, which is particularly useful when the detected object cannot transmit its own information. For example, CPM can convey the location / positioning, speed, heading, and / or type of a detected object (depending on what information the transmitting vehicle can determine). Therefore, in Figure 10 In the example, vehicle B broadcasts one or more CPMs indicating that vehicle A exists at depth 3-C. By receiving and decoding the CPMs from vehicle B, the self-vehicle can now "see" vehicle A located at depth 3-C.

[0151] Similar to the case using BSM, the driving strategy for autonomous vehicles can refine the search tree of possible trajectories by pruning infeasible paths and / or nodes (e.g., depth 3-C). Therefore, in Figure 10 In the example, CPM from vehicle B helps remove / prune / reduce the weight of depths 3-C and 4-C from the search tree of possible trajectories / nodes. Using CPM to prune trajectories / nodes helps driving policies achieve higher performance. For example, driving policies can refocus trajectory and / or node assignments on depths 3-A and 3-B, which are truly promising search areas.

[0152] Even if the CPM from vehicle B does not explicitly or accurately model all information about vehicle A, the driving strategy still benefits. For example, if the CPM simply provides the message "the road ahead looks congested," this information can be probabilistically incorporated into a tree search algorithm (e.g., Monte Carlo tree search). For instance, some uncertainty modeling can be added to reward backpropagation, causing subtrees from depth 3-C (even without explicit knowledge of vehicle A) to receive less reward due to the presence of this unknown / uncertain condition. This also concentrates more computational resources on depths 3-A and 3-B due to the uncertainty at depth 3-C.

[0153] Figure 11 This is illustration 1100 of another example driving scenario according to various aspects of this disclosure, where CPM can be used to trim possible route trajectories. As... Figure 11 As shown, the autonomous vehicle is calculating the trajectory around another vehicle (denoted as "B") in the same lane at depth 2. However, in Figure 11 In the example, the autonomous vehicle cannot see the third vehicle (represented as "A") in front of vehicle B in the same lane. Therefore, depth 3-C (the position of vehicle A) is considered a feasible option by the autonomous vehicle's driving strategy.

[0154] exist Figure 11In the example, neither vehicle A nor vehicle B is a V2X-capable vehicle. However, there is a RSU (Roadside Unit) equipped with sensors and V2X capability along the highway. In this case, the RSU broadcasts CPM (Continuous Motion Rate) which is received and decoded by the autonomous vehicle. While the autonomous vehicle might be able to detect the presence of vehicle B using its own sensors, it can now "see" vehicle A based on the CPM received from the RSU.

[0155] As in the example above, the driving strategy of a self-driving vehicle can be refined by pruning the search tree of possible trajectories through cutting infeasible paths and / or nodes (e.g., depth 3-C). Therefore, in Figure 11 In the example, CPM from the RSU helps remove / prune / reduce the weight of depths 3-C and 4-C from the search tree of possible tracks / nodes. Using CPM to prune tracks / nodes helps driving policies achieve higher performance. For example, driving policies can refocus track and / or node assignments on depths 3-A and 3-B, which are truly promising search areas.

[0156] As a third use case, V2X messages can be manipulation sharing and coordination messages (MSCM). Figure 12A and Figure 12B An example driving scenario according to various aspects of this disclosure is illustrated, where MSCM can be used to trim possible route trajectories. As shown in Figure 1200, the autonomous vehicle is calculating the trajectory (e.g., overtaking trajectory) around another vehicle (denoted as "B") in the same lane at depth 2. However, in Figure 12A In the example, the autonomous vehicle cannot (e.g., using its onboard sensors, such as radar camera sensor module 320) see another non-V2X-capable vehicle (denoted as "A") in front of vehicle B in the same lane. Therefore, depth 3-C (the position of vehicle A) is considered a feasible option by the autonomous vehicle's driving strategy. Furthermore, vehicle A intends to perform some maneuver (e.g., change lanes) to avoid vehicle B.

[0157] MSCM is used to share and coordinate intentional driving maneuvers (e.g., maneuvers over the next few seconds to minutes). Unlike local planning, MSCM optimizes the planned trajectory by considering the planned trajectories of other vehicles. The protocol employs a request-response design. The requester (e.g., vehicle A in the example of Figure 12) sends one or more MSCMs to other maneuver participants (e.g., self-driving vehicles in the example of Figure 12), detailing the maneuver to be performed by the requester and optional other participants (if other participants need to perform any maneuvers related to the maneuver planned by the requester). Each participant sends a response (another MSCM) to the requester, indicating whether the responder agrees or disagrees with the planned maneuver. A single negative response ends the maneuver negotiation (the working phase of the protocol). Consistent positive responses cause the maneuver to begin. During the maneuver, participants can send MSCMs to cancel an ongoing maneuver (e.g., due to a flat tire). Once each participant (via MSCM) confirms completion of their designated maneuver, the maneuver is considered complete. Note that for special vehicles (e.g., police, emergency responders), there is no maneuver negotiation.

[0158] MSCM control requests can be sent via unicast, multicast, or broadcast. In unicast mode, the requester negotiates control with a single vehicle. In multicast mode, the requester can adjust signal strength and direct the signal beam to negotiate control with a subset of surrounding vehicles. Finally, in broadcast mode, the requester negotiates control with all vehicles within range.

[0159] Continue to refer to Figure 12A and Figure 12B Vehicle A can transmit an MSCM request to share its lane-changing intent with the autonomous vehicle. The autonomous vehicle now has a driving strategy consistent with vehicle A's plan. Therefore, as shown in Figure 1250, the use of MSCM significantly refines the trajectory tree. The maneuvering intent indicated by the MSCM request from vehicle A allows the autonomous vehicle to understand vehicle A's entire future trajectory. This reduces the uncertainty assigned to vehicle A because it is simulated through the depth of the search algorithm / tree, and the autonomous vehicle can have greater confidence in its generated plan.

[0160] As a fourth use case, V2X messaging can be distributed environment notification messages (DENM). Figure 13A and Figure 13B An example driving scenario according to various aspects of this disclosure is illustrated, where DENM can be used to trim possible route trajectories. As shown in Figure 1300, the autonomous vehicle is calculating the trajectory (e.g., overtaking trajectory) around another vehicle (denoted as "B") in the same lane at depth 2. However, in Figure 13AIn the example, because vehicle A is parked along the roadside, vehicle B is unaware of the safe zone ahead of vehicle B.

[0161] exist Figure 13A and Figure 13B In the example, a sensor-equipped RSU with V2X capability knows the safety zone caused by vehicle A. In this case, the RSU can send one or more DENMs indicating that vehicle A is stationary and a safety zone exists around the event. DENMs are primarily used by Collaborative Road Obstacle Warning (RHW) applications to alert road users to detected events. Upon detecting an event corresponding to an RHW use case, the RSU immediately broadcasts the DENM to other RSUs and / or V2X-capable vehicles located within the geographic area related to the event. The DENM broadcast continues as long as the event exists. Once the event disappears (after a predefined expiry time), the termination of the DENM broadcast is automatic, or the RSU generates a special DENM to notify that the event has disappeared. DENMs can be used to issue warnings regarding emergency braking of vehicles, wrong-way driving, vehicle stationary (due to an accident or vehicle problem), traffic condition warnings, signal violation warnings, road construction warnings, collision risk warnings, hazardous locations, precipitation, slippery roads, low visibility, or strong winds.

[0162] As shown in Figure 1350, based on the received DENM, the autonomous vehicle can update its driving strategy to avoid safe zones (e.g., pruning subtrees that conflict with safe zones). Similar to the previous example, this significantly refines the trajectory represented by the search tree, thereby improving the performance of the driving strategy.

[0163] Continue to refer to Figure 13A and Figure 13B In the example scenario shown, the RSU can send more than just indications of a safe zone. Instead, the RSU can provide information that allows the autonomous vehicle to fully understand how the world might evolve within the area observed by the RSU. In this case, the RSU can use the same algorithms as the autonomous vehicle to "plan" the trajectory. The RSU can build subtrees that can be inserted or expanded very efficiently along with the autonomous vehicle's search tree.

[0164] More specifically, while the RSU understands stationary vehicles, it can develop one or more route plans known to be safe for navigation in the space (e.g., via Monte Carlo tree search). The RSU can then send these plans to V2X-capable vehicles approaching the scene (e.g., Figure 13A and Figure 13BThe receiving self-transporter can then (1) accept the plan as the trajectory it will execute, or (2) add the plan to its own search tree as a priori. This "priori" can take the form of "guidance" (which is largely biased towards actions at each node branch to prioritize actions that closely follow the plan provided by the RSU) or through rewards (similar to a heavily rewarded trajectory of the plan provided by the RSU).

[0165] This concept can be extended beyond the RSU. For example, other V2X-capable autonomous or semi-autonomous vehicles can pass on their newly calculated safe trajectories to other V2X-capable vehicles behind them. In this way, each new vehicle traversing a given space builds upon a set of calculations recently performed by its predecessor. In some cases, the RSU can act as a relay, aggregating promising actions detected by all nearby vehicles and then providing them to other vehicles.

[0166] In some cases, V2X-capable vehicles can send multiple types of V2X messages, such as one or more BSM, CPM, and / or MSCM. The autonomous vehicle can then apply its driving strategy to information received from other V2X-capable vehicles. The goal is to predict multiple depths of the future trajectories of other V2X-capable vehicles, thereby improving the autonomous vehicle's trajectory / route planning.

[0167] Figure 14A to Figure 14C An example driving scenario according to various aspects of this disclosure is illustrated, in which various V2X messages can be used to prune possible route trajectories. As shown in Figure 1400, a V2X-capable vehicle (denoted as "A") has calculated and is now sharing an intended trajectory to merge onto the highway where the self-driving vehicle is driving. For example, the intended trajectory can be sent in one or more MSCMs (via unicast, multicast, or broadcast). However, in Figure 14A In the example, the autonomous vehicle cannot see (e.g., using its onboard sensors, such as radar camera sensor module 320) vehicle A because it is located, for example, behind an obstacle separating the merging lane from the highway.

[0168] As shown in Figure 1430, the autonomous vehicle is calculating a trajectory (e.g., an overtaking trajectory) around another vehicle (denoted as "B") in the same lane. Using the intention trajectory received from vehicle A, the autonomous vehicle can prune certain macro-actions from the trajectory tree. Specifically... Figure 14BAs shown, the driving strategy of a self-driving vehicle can trim macro-actions that overlap with macro-actions indicated by vehicle A, macro-actions connected to trimmed macro-actions, and nodes connected to trimmed macro-actions. In this way, the driving strategy of the self-driving vehicle is based on other V2X vehicles (e.g., Figure 14A to Figure 14C Adjust the driving strategy for vehicle A in the text.

[0169] Figure 1450 illustrates the search tree for results from the autonomous vehicle. As will be understood, this technique helps the driving strategy engine find the optimal trajectory more computationally efficient, for example, by storing fewer impossible maneuvers and improving its time-efficiency strategy (e.g., the lane is occupied for X seconds, therefore no related prediction is needed). This technique thus introduces cooperative driving strategies (i.e., in the presence of other vehicles with V2X capabilities, such as autonomous vehicles and other vehicles with V2X capabilities, such as autonomous vehicles and other vehicles with V2X capabilities). Figure 14A to Figure 14C Between modes of transportation A).

[0170] refer to Figure 14A to Figure 14C The described technology can be particularly advantageous for low-spec V2X-capable vehicles. Specifically, since these vehicles may have fewer (if any) sensors (e.g., radar camera sensor module 320), the aforementioned V2X sensing technology can fill any gaps in perception and route planning capabilities. Low-spec vehicles may also, or alternatively, lack the computational bandwidth for high-fidelity tree search, but each individual vehicle, capable of broadcasting its intent / desire and assembling surrounding components, can effectively reconstruct a high-fidelity decision block.

[0171] Figure 15 This is a diagram 1500 illustrating an example driving strategy pipeline based on V2X trajectory processing, according to various aspects of this disclosure. Figure 15 As shown, at the advanced level, sensing and perception information (e.g., from camera 312, radar 314, lidar sensor 316, sensor 322) and V2X information (e.g., from one or more V2X messages) are fed into the RWM block. The RWM block outputs map data (e.g., from map 302), object detection results (e.g., for both stationary and moving objects), trajectory predictions for detected moving objects, vehicle locations, and any shared trajectories from V2X messages (e.g., MSCM) to the lane-level planner block, the global trajectory search block, and the motion planning block.

[0172] The above reference Figure 5 The lane-level planner block and global trajectory search block, discussed in more detail, can use available shared trajectories from V2X messages for route planning, as shown in the figure above. Figure 9 to Figure 14C The discussion. With Figure 5The illustrated pipeline differs in that the motion planning block includes a shared local trajectory optimization block and an ego local trajectory optimization block. The shared local trajectory optimization block determines the optimal trajectory within the shared trajectory, while the ego local trajectory optimization block determines the optimal trajectory for the vehicle itself. The shared local trajectory optimization block communicates with the shared control service, while the ego local trajectory optimization block provides control signals to the vehicle control system.

[0173] More specifically, the autonomous vehicle's trajectory can be part of a shared local trajectory. For example, the autonomous vehicle might intend to overtake another vehicle. For this, the autonomous vehicle needs to share its trajectory, which is processed by the shared local trajectory optimization block. Alternatively, the shared local trajectory may include the autonomous vehicle's trajectory. For example, another vehicle might request the autonomous vehicle to move to a different lane. The shared trajectory would include the trajectory requested by the autonomous vehicle. The shared local trajectory optimization block then determines whether the requested autonomous vehicle trajectory is being optimized or is worsening the current autonomous vehicle trajectory.

[0174] It should be noted that in some cases, an RSU (e.g., base station / RSU 404) or network entity (e.g., network entity 406) (such as an edge server) can act as a virtual onboard computer for one or more V2X-capable vehicles (e.g., V2X-capable vehicle 300). For example, as described herein, the RSU / server can receive V2X messages transmitted near the V2X-capable vehicle and can determine feasible trajectories and provide these feasible trajectories to the V2X-capable vehicle to reduce the number of processing operations performed by the V2X-capable vehicle.

[0175] Figure 16 An example method 1600 for wireless communication according to various aspects of this disclosure is illustrated. In one aspect, method 1600 may be performed by a first V2X-capable vehicle (e.g., V2X-capable vehicle 300, OBC 380, or any other V2X-capable vehicle described herein).

[0176] At 1610, the first V2X-capable vehicle receives from the second V2X-capable vehicle one or more V2X messages (e.g., BSM) indicative of the driving status of the second V2X-capable vehicle, wherein the driving status includes the position of the second V2X-capable vehicle, the speed of the second V2X-capable vehicle, the heading of the second V2X vehicle, or any combination thereof. In one aspect, operation 1610 may be performed by one or more WWAN transceivers 330, one or more short-range wireless transceivers 340, one or more processors 306, memory 304, and / or driving strategy components 318, any one or all of which can be considered as components for performing this operation.

[0177] At 1620, the first V2X-capable vehicle determines a feasible driving trajectory of the first V2X-capable vehicle from multiple potential driving trajectories of the first V2X-capable vehicle, at least in part based on the driving state of the second V2X-capable vehicle, as described above with reference to at least [reference needed]. Figure 9 As described. In one aspect, operation 1620 may be performed by one or more WWAN transceivers 330, one or more short-range wireless transceivers 340, one or more processors 306, memory 304 and / or driving strategy components 318, any one or all of which may be regarded as components for performing this operation.

[0178] Figure 17 An example method 1700 for wireless communication according to various aspects of this disclosure is illustrated. In one aspect, method 1700 may be performed by a vehicle with V2X capability (e.g., a vehicle with V2X capability 300, an OBC 380, or any other vehicle with V2X capability described herein).

[0179] At 1710, the V2X-capable vehicle receives from the V2X-capable device one or more V2X messages (e.g., CPM) indicating at least the presence of one or more objects detected by the sensing sensors of the V2X-capable device. In one aspect, operation 1710 may be performed by one or more WWAN transceivers 330, one or more short-range wireless transceivers 340, one or more processors 306, memory 304, and / or driving strategy components 318, any or all of which can be considered as components for performing this operation.

[0180] At 1720, the V2X-capable vehicle determines a feasible driving trajectory from multiple potential driving trajectories of the V2X-capable vehicle, at least in part, based on the presence of one or more objects detected by these sensing sensors of the V2X-capable device, as described above, at least referring to...Figure 10 As described. In one aspect, operation 1720 may be performed by one or more WWAN transceivers 330, one or more short-range wireless transceivers 340, one or more processors 306, memory 304 and / or driving strategy components 318, any one or all of which may be regarded as components for performing this operation.

[0181] Figure 18 An example method 1800 for wireless communication according to various aspects of this disclosure is illustrated. In one aspect, method 1800 may be performed by a first V2X-capable vehicle (e.g., V2X-capable vehicle 300, OBC 380, or any other V2X-capable vehicle described herein).

[0182] At 1810, the first V2X-capable vehicle receives from the second V2X-capable vehicle one or more V2X messages (e.g., MSCM) instructing the second V2X-capable vehicle on its intended driving maneuvers. In one aspect, operation 1810 may be performed by one or more WWAN transceivers 330, one or more short-range wireless transceivers 340, one or more processors 306, memory 304, and / or driving strategy components 318, any or all of which can be considered as components for performing this operation.

[0183] At 1820, the first V2X-capable vehicle determines a feasible driving trajectory for the V2X-capable vehicle from multiple potential driving trajectories, based at least in part on the presence of one or more objects detected by these sensing sensors of the V2X-capable device, as at least referred to above. Figure 12A to Figure 12B As described. In one aspect, operation 1820 may be performed by one or more WWAN transceivers 330, one or more short-range wireless transceivers 340, one or more processors 306, memory 304 and / or driving strategy components 318, any one or all of which may be regarded as components for performing this operation.

[0184] Figure 19 An example method 1900 for wireless communication according to various aspects of this disclosure is illustrated. In one aspect, method 1900 may be performed by a vehicle with V2X capability (e.g., a vehicle with V2X capability 300, an OBC 380, or any other vehicle with V2X capability described herein).

[0185] At 1910, the V2X-capable vehicle receives from the V2X-capable device one or more V2X messages (e.g., DENM) indicating at least one detected event associated with the road on which the V2X-capable vehicle is traveling. In one aspect, operation 1910 may be performed by one or more WWAN transceivers 330, one or more short-range radio transceivers 340, one or more processors 306, memory 304, and / or driving strategy components 318, any or all of which can be considered as components for performing this operation.

[0186] At 1920, the V2X-capable vehicle determined a feasible driving trajectory for the V2X-capable vehicle from multiple potential driving trajectories based at least in part on at least one detected event, as referenced above. Figure 13A to Figure 13B As described. In one aspect, operation 1920 may be performed by one or more WWAN transceivers 330, one or more short-range wireless transceivers 340, one or more processors 306, memory 304 and / or driving strategy components 318, any one or all of which may be regarded as components for performing this operation.

[0187] Figure 20 An example method 2000 for wireless communication according to various aspects of this disclosure is illustrated. In one aspect, method 2000 may be performed by a first V2X-capable vehicle (e.g., V2X-capable vehicle 300, OBC 380, or any other V2X-capable vehicle described herein).

[0188] At point 2010, the first V2X-capable vehicle receives one or more V2X messages (e.g., one or more BSM, CPM, MSCM, DENM, or any combination thereof) from a V2X-capable device (e.g., a second V2X-capable vehicle, a third V2X-capable vehicle, or roadside infrastructure) instructing the intended driving path of the second V2X-capable vehicle. In one aspect, operation 2010 may be performed by one or more WWAN transceivers 330, one or more short-range radio transceivers 340, one or more processors 306, memory 304, and / or driving strategy components 318, any one or all of which may be considered as components for performing this operation.

[0189] At 2020, the first V2X-capable vehicle determined its feasible driving trajectory from multiple potential driving trajectories based at least in part on the driving state of the second V2X-capable vehicle, as referenced above. Figure 14A to Figure 14CAs described. In one aspect, operation 2020 may be performed by one or more WWAN transceivers 330, one or more short-range wireless transceivers 340, one or more processors 306, memory 304 and / or driving strategy components 318, any one or all of which may be regarded as components for performing this operation.

[0190] As will be understood, the technical advantage of methods 1600 to 2000 is improved route planning, especially in the absence of sensing information from the (first) perception sensors of the V2X-capable vehicle (e.g., due to visual obstruction, weather, etc.).

[0191] As can be seen in the detailed description above, different features are grouped together in the examples. This manner of disclosure should not be construed as an intention to have more features than those explicitly mentioned in each clause. Rather, the various aspects of this disclosure may include fewer features than those in the individual example clauses disclosed. Therefore, the following clauses should be regarded accordingly as incorporated into the description, where each clause may serve as a separate example. Although each dependent clause may refer in the clause to a specific combination with one of the other clauses, the aspect of that dependent clause is not limited to that specific combination. It should be understood that other example clauses may also include combinations of aspects of a dependent clause with the subject matter of any other dependent or independent clause, or combinations of any feature with other dependent and independent clauses. The various aspects disclosed herein explicitly include these combinations unless explicitly stated or readily inferred that a particular combination is not intended for use (e.g., contradictory aspects, such as defining an element as both an electrical insulator and an electrical conductor). Furthermore, it is contemplated that aspects of a clause may be included in any other independent clause, even if that clause does not directly depend on the independent clause.

[0192] Specific implementation examples are described in the following numbered clauses:

[0193] Clause 1. A method of wireless communication performed by a first vehicle-to-everything (V2X) capable vehicle, the method comprising: receiving from a V2X capable device one or more V2X messages indicating an intended driving path of a second V2X capable vehicle; and determining a feasible driving trajectory of the first V2X capable vehicle from a plurality of potential driving trajectories of the first V2X capable vehicle, at least in part based on the intended driving path of the second V2X capable vehicle.

[0194] Clause 2. The method according to Clause 1, wherein determining the feasible driving trajectory comprises: determining an infeasible driving trajectory from the plurality of potential driving trajectories based at least in part on the intended driving path of the second V2X-capable vehicle; and removing the infeasible driving trajectory from the plurality of potential driving trajectories to determine a set of remaining driving trajectories from the plurality of potential driving trajectories, wherein the feasible driving trajectory of the first V2X-capable vehicle is a remaining driving trajectory from the set of remaining driving trajectories.

[0195] Clause 3. The method according to Clause 2 further includes: sending the set of remaining driving trajectories to one or more other V2X-capable vehicles, roadside infrastructure, or any combination thereof; or sending the remaining driving trajectories to the one or more other V2X-capable vehicles, the roadside infrastructure, or any combination thereof.

[0196] Clause 4. The method according to any one of Clauses 1 to 3, wherein determining the feasible driving trajectory comprises: determining an infeasible driving trajectory among the plurality of potential driving trajectories based at least in part on the intended driving path of the second V2X-capable vehicle; and reassigning nodes from the infeasible driving trajectory to remaining driving trajectories among the plurality of potential driving trajectories, wherein the feasible driving trajectory of the first V2X-capable vehicle is a remaining driving trajectory among the plurality of potential driving trajectories, wherein each node represents a location on a potential driving trajectory by a macro-action of one or more macro-actions, and wherein each macro-action represents a portion of a lane of a road on which the first V2X-capable vehicle is traveling.

[0197] Clause 5. The method according to any one of Clauses 1 to 4, wherein determining the feasible driving trajectory comprises: establishing a first search tree of the plurality of potential driving trajectories, wherein each of the plurality of potential driving trajectories corresponds to a subtree of the first search tree.

[0198] Clause 6. The method according to Clause 5, wherein: each subtree of the first search tree includes one or more first macro actions, each first macro action representing a portion of a lane of a road on which the first V2X-capable vehicle, the second V2X-capable vehicle, or both are driving, each first macro action is associated with one or more first nodes, and each first node represents a location on a potential driving trajectory via the portion of the lane of the road represented by the corresponding first macro action.

[0199] Clause 7. The method according to Clause 6, wherein: the intended driving path is represented as a subtree of a second search tree of the second V2X-capable vehicle, the subtree of the second search tree comprising one or more second macro actions, each second macro action representing a portion of a lane of the road on which the first V2X-capable vehicle, the second V2X-capable vehicle, or both are driving, each second macro action being associated with one or more second nodes, each second node representing a location within the portion of the lane of the road represented by the corresponding second macro action.

[0200] Clause 8. The method according to Clause 7, wherein determining the feasible driving trajectory comprises: determining, at least in part, a subtree of a first search tree corresponding to an infeasible driving trajectory among the plurality of potential driving trajectories, based on the subtree representing the intended driving path of the second V2X-capable vehicle; and removing the subtree of the first search tree corresponding to the infeasible driving trajectory from the plurality of potential driving trajectories, wherein the feasible driving trajectory of the first V2X-capable vehicle corresponds to the remaining subtree of the first search tree.

[0201] Clause 9. The method described in Clause 8 further includes sending the remaining subtree to one or more other V2X-capable vehicles, roadside infrastructure, or any combination thereof.

[0202] Clause 10. The method described in Clause 9, wherein the one or more other V2X-capable vehicles include the second V2X-capable vehicle.

[0203] Clause 11. The method according to any one of Clauses 7 to 10, wherein determining the feasible driving trajectory comprises: determining, at least in part, a subtree of a first search tree corresponding to an infeasible driving trajectory among the plurality of potential driving trajectories, based on the subtree representing the intended driving path of the second V2X-capable vehicle; and reallocating nodes from the subtree of the first search tree corresponding to the infeasible driving trajectory to the remaining subtree of the first search tree, wherein the feasible driving trajectory of the first V2X-capable vehicle corresponds to the remaining subtree of the first search tree.

[0204] Clause 12. The method described in Clause 11 further includes: sending the remaining subtree to one or more other V2X-capable vehicles, roadside infrastructure, or any combination thereof.

[0205] Clause 13. The method according to any one of Clauses 5 to 12, wherein the first search tree includes a Monte Carlo tree search.

[0206] Clause 14. The method according to any one of Clauses 1 to 13, wherein the one or more V2X messages include: one or more Basic Security Messages (BSM), one or more Collective Awareness Messages (CPM), one or more Manipulation Sharing and Coordination Messages (MSCM), one or more Distributed Environment Notification Messages (DENM), or any combination thereof.

[0207] Clause 15. The method according to any one of Clauses 1 to 14, the method further comprising: sending the feasible driving trajectory to at least one or more other V2X-capable vehicles, roadside infrastructure, or any combination thereof; receiving one or more driving trajectories from the one or more other V2X-capable vehicles, the roadside infrastructure, or any combination thereof, wherein the feasible driving trajectory is further determined based on the one or more driving trajectories; or any combination thereof.

[0208] Clause 16. The method according to Clause 15, wherein: the feasible driving trajectory is represented as a subtree of a search tree of the first V2X-capable vehicle, the subtree of the search tree comprising one or more macro actions, each macro action representing a portion of a lane of the road on which the first V2X-capable vehicle, the second V2X-capable vehicle, or both are driving, each macro action being associated with one or more nodes, each node representing a location within the portion of the lane of the road represented by the corresponding macro action.

[0209] Clause 17. The method according to any one of Clauses 1 to 16, the method further comprising: performing driving maneuvers according to the feasible driving trajectory.

[0210] Clause 18. The method according to Clause 17, wherein the driving maneuver includes: changing lanes; merging onto a road on which the first V2X-capable vehicle, the second V2X-capable vehicle, or both are driving; an emergency braking event; turning onto another road different from the road on which the first V2X-capable vehicle, the second V2X-capable vehicle, or both are driving; or leaving the road on which the first V2X-capable vehicle, the second V2X-capable vehicle, or both are driving.

[0211] Clause 19. The method according to any one of Clauses 1 to 18, wherein the V2X-capable device is: the second V2X-capable vehicle, the third V2X-capable vehicle, or roadside infrastructure.

[0212] Clause 20. A first vehicle-to-everything (V2X) capable vehicle, the first vehicle-to-everything (V2X) capable vehicle comprising: one or more memories; one or more transceivers; and one or more processors communicatively coupled to the one or more memories and the one or more transceivers, the one or more processors being individually or in combination configured to: receive, via the one or more transceivers, one or more V2X messages from a V2X capable device indicating an intended driving path of a second V2X capable vehicle; and determine a feasible driving trajectory of the first V2X capable vehicle from a plurality of potential driving trajectories of the first V2X capable vehicle, at least in part based on the intended driving path of the second V2X capable vehicle.

[0213] Clause 21. A first V2X-capable vehicle as described in Clause 20, wherein the one or more processors are configured to determine the feasible driving trajectory, including the one or more processors being configured individually or in combination to: determine an infeasible driving trajectory from a plurality of potential driving trajectories based at least in part on the intended driving path of the second V2X-capable vehicle; and remove the infeasible driving trajectory from the plurality of potential driving trajectories to determine a set of remaining driving trajectories from the plurality of potential driving trajectories, wherein the feasible driving trajectory of the first V2X-capable vehicle is a remaining driving trajectory from the set of remaining driving trajectories.

[0214] Clause 22. The first V2X-capable vehicle as described in Clause 21, wherein the one or more processors are further configured individually or in combination to: transmit the set of remaining driving trajectories via the one or more transceivers to one or more other V2X-capable vehicles, roadside infrastructure, or any combination thereof; or transmit the remaining driving trajectories via the one or more transceivers to the one or more other V2X-capable vehicles, the roadside infrastructure, or any combination thereof.

[0215] Clause 23. A first V2X-capable vehicle under any one of Clauses 20 to 22, wherein the one or more processors are configured to determine the feasible driving trajectory, comprising the one or more processors individually or in combination being configured to: determine an infeasible driving trajectory among a plurality of potential driving trajectories based at least in part on the intended driving path of the second V2X-capable vehicle; and reassign nodes from the infeasible driving trajectories to remaining driving trajectories among the plurality of potential driving trajectories, wherein the feasible driving trajectory of the first V2X-capable vehicle is a remaining driving trajectory among the plurality of potential driving trajectories, wherein each node represents a location on a potential driving trajectory by a macro-action of one or more macro-actions, and wherein each macro-action represents a portion of a lane of a road on which the first V2X-capable vehicle is traveling.

[0216] Clause 24. A first V2X-capable vehicle according to any one of Clauses 20 to 23, wherein the one or more processors are configured to determine the feasible driving trajectory, including the one or more processors being configured individually or in combination to: establish a first search tree of the plurality of potential driving trajectories, wherein each of the plurality of potential driving trajectories corresponds to a subtree of the first search tree.

[0217] Clause 25. The first V2X-capable vehicle as described in Clause 24, wherein: each subtree of the first search tree includes one or more first macro actions, each first macro action representing a portion of a lane of a road on which the first V2X-capable vehicle, the second V2X-capable vehicle, or both are driving, each first macro action being associated with one or more first nodes, and each first node representing a location on a potential driving trajectory via the portion of the lane of the road represented by the corresponding first macro action.

[0218] Clause 26. The first V2X-capable vehicle as described in Clause 25, wherein: the intended driving path is represented as a subtree of a second search tree of the second V2X-capable vehicle, the subtree of the second search tree comprising one or more second macro actions, each second macro action representing a portion of a lane of the road on which the first V2X-capable vehicle, the second V2X-capable vehicle, or both are driving, each second macro action being associated with one or more second nodes, each second node representing a location within the portion of the lane of the road represented by the corresponding second macro action.

[0219] Clause 27. A first V2X-capable vehicle as described in Clause 26, wherein the one or more processors are configured to determine the feasible driving trajectory, including the one or more processors individually or in combination being configured to: determine, at least in part, a subtree of a first search tree corresponding to an infeasible driving trajectory among the plurality of potential driving trajectories based on the subtree representing the intended driving path of the second V2X-capable vehicle; and remove the subtree of the first search tree corresponding to the infeasible driving trajectory from the plurality of potential driving trajectories, wherein the feasible driving trajectory of the first V2X-capable vehicle corresponds to the remaining subtree of the first search tree.

[0220] Clause 28. The first V2X-capable vehicle as described in Clause 27, wherein the one or more processors are further configured individually or in combination to transmit the remaining subtree via the one or more transceivers to one or more other V2X-capable vehicles, roadside infrastructure, or any combination thereof.

[0221] Clause 29. The first V2X-capable vehicle as described in Clause 28, wherein the one or more other V2X-capable vehicles include the second V2X-capable vehicle.

[0222] Clause 30. A first V2X-capable vehicle under any one of Clauses 26 to 29, wherein the one or more processors are configured to determine the feasible driving trajectory, wherein the one or more processors are individually or in combination configured to: determine, at least in part, a subtree of a first search tree corresponding to an infeasible driving trajectory among the plurality of potential driving trajectories, based on the subtree representing the intended driving path of the second V2X-capable vehicle; and reallocate nodes from the subtree of the first search tree corresponding to the infeasible driving trajectory to the remaining subtree of the first search tree, wherein the feasible driving trajectory of the first V2X-capable vehicle corresponds to the remaining subtree of the first search tree.

[0223] Clause 31. The first V2X-capable vehicle as described in Clause 30, wherein the one or more processors are further configured individually or in combination to transmit the remaining subtree to one or more other V2X-capable vehicles, roadside infrastructure, or any combination thereof via the one or more transceivers.

[0224] Clause 32. A first V2X-capable vehicle under any one of Clauses 24 to 31, wherein the first search tree includes Monte Carlo tree search.

[0225] Clause 33. A first V2X-capable vehicle pursuant to any one of Clauses 20 to 32, wherein the one or more V2X messages include: one or more Basic Safety Messages (BSM), one or more Collective Sense Messages (CPM), one or more Maneuver Sharing and Coordination Messages (MSCM), one or more Distributed Environment Notification Messages (DENM), or any combination thereof.

[0226] Clause 34. A first V2X-capable vehicle pursuant to any one of Clauses 20 to 33, wherein the one or more processors are further configured individually or in combination to: transmit the feasible driving trajectory via the one or more transceivers to at least one or more other V2X-capable vehicles, roadside infrastructure, or any combination thereof; receive one or more driving trajectories via the one or more transceivers from the one or more other V2X-capable vehicles, the roadside infrastructure, or any combination thereof, wherein the feasible driving trajectory is further determined based on the one or more driving trajectories; or any combination thereof.

[0227] Clause 35. The first V2X-capable vehicle as described in Clause 34, wherein: the feasible driving trajectory is represented as a subtree of a search tree of the first V2X-capable vehicle, the subtree of the search tree comprising one or more macro actions, each macro action representing a portion of a lane of the road on which the first V2X-capable vehicle, the second V2X-capable vehicle, or both are driving, each macro action being associated with one or more nodes, each node representing a location within the portion of the lane of the road represented by the corresponding macro action.

[0228] Clause 36. A first V2X-capable vehicle according to any one of Clauses 20 to 35, wherein the one or more processors are further configured individually or in combination to perform driving maneuvers according to the feasible driving trajectory.

[0229] Clause 37. The first V2X-capable vehicle as described in Clause 36, wherein the driving maneuvers include: changing lanes; merging onto a road on which the first V2X-capable vehicle, the second V2X-capable vehicle, or both are driving; an emergency braking event; turning onto another road different from the road on which the first V2X-capable vehicle, the second V2X-capable vehicle, or both are driving; or leaving the road on which the first V2X-capable vehicle, the second V2X-capable vehicle, or both are driving.

[0230] Clause 38. A first V2X-capable vehicle under any one of Clauses 20 to 37, wherein the V2X-capable device is: a second V2X-capable vehicle, a third V2X-capable vehicle, or roadside infrastructure.

[0231] Clause 39. A first vehicle-to-everything (V2X) capable vehicle, the first V2X capable vehicle comprising: means for receiving from a V2X capable device one or more V2X messages indicating an intended driving path of a second V2X capable vehicle; and means for determining a feasible driving trajectory of the first V2X capable vehicle from a plurality of potential driving trajectories of the first V2X capable vehicle, at least in part based on the intended driving path of the second V2X capable vehicle.

[0232] Clause 40. The first V2X-capable vehicle as described in Clause 39, wherein the components for determining the feasible driving trajectory include: components for determining an infeasible driving trajectory among a plurality of potential driving trajectories based at least in part on the intended driving path of the second V2X-capable vehicle; and components for removing the infeasible driving trajectory from the plurality of potential driving trajectories to determine a set of remaining driving trajectories among the plurality of potential driving trajectories, wherein the feasible driving trajectory of the first V2X-capable vehicle is a remaining driving trajectory among the set of remaining driving trajectories.

[0233] Clause 41. The first V2X-capable vehicle as described in Clause 40, the first V2X-capable vehicle further comprising: a component for transmitting the set of remaining driving trajectories to one or more other V2X-capable vehicles, roadside infrastructure, or any combination thereof; or a component for transmitting the remaining driving trajectories to the one or more other V2X-capable vehicles, the roadside infrastructure, or any combination thereof.

[0234] Clause 42. A first V2X-capable vehicle according to any one of Clauses 39 to 41, wherein the components for determining the feasible driving trajectory include: components for determining an infeasible driving trajectory among the plurality of potential driving trajectories based at least in part on the intended driving path of the second V2X-capable vehicle; and components for reassigning nodes from the infeasible driving trajectory to remaining driving trajectories among the plurality of potential driving trajectories, wherein the feasible driving trajectory of the first V2X-capable vehicle is a remaining driving trajectory among the plurality of potential driving trajectories, wherein each node represents a location on a potential driving trajectory by a macro-action of one or more macro-actions, and wherein each macro-action represents a portion of a lane of a road on which the first V2X-capable vehicle is traveling.

[0235] Clause 43. A first V2X-capable vehicle according to any one of Clauses 39 to 42, wherein the components for determining the feasible driving trajectory include: components for establishing a first search tree of the plurality of potential driving trajectories, wherein each of the plurality of potential driving trajectories corresponds to a subtree of the first search tree.

[0236] Clause 44. The first V2X-capable vehicle as described in Clause 43, wherein: each subtree of the first search tree includes one or more first macro actions, each first macro action representing a portion of a lane of a road on which the first V2X-capable vehicle, the second V2X-capable vehicle, or both are driving, each first macro action being associated with one or more first nodes, and each first node representing a location on a potential driving trajectory via the portion of the lane of the road represented by the corresponding first macro action.

[0237] Clause 45. The first V2X-capable vehicle as described in Clause 44, wherein: the intended driving path is represented as a subtree of a second search tree of the second V2X-capable vehicle, the subtree of the second search tree comprising one or more second macro actions, each second macro action representing a portion of a lane of the road on which the first V2X-capable vehicle, the second V2X-capable vehicle, or both are driving, each second macro action being associated with one or more second nodes, each second node representing a location within the portion of the lane of the road represented by the corresponding second macro action.

[0238] Clause 46. The first V2X-capable vehicle as described in Clause 45, wherein the components for determining the feasible driving trajectory include: components for determining, at least in part, a subtree of a first search tree corresponding to an infeasible driving trajectory among the plurality of potential driving trajectories, based on the subtree representing the intended driving path of the second V2X-capable vehicle; and components for removing the subtree of the first search tree corresponding to the infeasible driving trajectory from the plurality of potential driving trajectories, wherein the feasible driving trajectory of the first V2X-capable vehicle corresponds to the remaining subtree of the first search tree.

[0239] Clause 47. The first V2X-capable vehicle as described in Clause 46, the first V2X-capable vehicle further comprising: a component for transmitting the remaining subtree to one or more other V2X-capable vehicles, roadside infrastructure, or any combination thereof.

[0240] Clause 48. The first V2X-capable vehicle as described in Clause 47, wherein the one or more other V2X-capable vehicles include the second V2X-capable vehicle.

[0241] Clause 49. A first V2X-capable vehicle according to any one of Clauses 45 to 48, wherein the components for determining the feasible driving trajectory include: components for determining, at least in part, a subtree of a first search tree corresponding to an infeasible driving trajectory among the plurality of potential driving trajectories, based on the subtree representing the intended driving path of the second V2X-capable vehicle; and components for reassigning nodes from the subtree of the first search tree corresponding to the infeasible driving trajectory to the remaining subtree of the first search tree, wherein the feasible driving trajectory of the first V2X-capable vehicle corresponds to the remaining subtree of the first search tree.

[0242] Clause 50. The first V2X-capable vehicle as described in Clause 49, the first V2X-capable vehicle further comprising: a component for transmitting the remaining subtree to one or more other V2X-capable vehicles, roadside infrastructure, or any combination thereof.

[0243] Clause 51. A first V2X-capable vehicle pursuant to any one of Clauses 43 to 50, wherein the first search tree comprises Monte Carlo tree search.

[0244] Clause 52. A first V2X-capable vehicle pursuant to any one of Clauses 39 to 51, wherein the one or more V2X messages include: one or more Basic Safety Messages (BSM), one or more Collective Sense Messages (CPM), one or more Maneuver Sharing and Coordination Messages (MSCM), one or more Distributed Environment Notification Messages (DENM), or any combination thereof.

[0245] Clause 53. A first V2X-capable vehicle under any one of Clauses 39 to 52, the first V2X-capable vehicle further comprising: components for transmitting the feasible driving trajectory to at least one or more other V2X-capable vehicles, roadside infrastructure, or any combination thereof; components for receiving one or more driving trajectories from the one or more other V2X-capable vehicles, the roadside infrastructure, or any combination thereof, wherein the feasible driving trajectory is further determined based on the one or more driving trajectories; or any combination thereof.

[0246] Clause 54. The first V2X-capable vehicle as described in Clause 53, wherein: the feasible driving trajectory is represented as a subtree of a search tree of the first V2X-capable vehicle, the subtree of the search tree comprising one or more macro actions, each macro action representing a portion of a lane of the road on which the first V2X-capable vehicle, the second V2X-capable vehicle, or both are driving, each macro action being associated with one or more nodes, each node representing a location within the portion of the lane of the road represented by the corresponding macro action.

[0247] Clause 55. The first V2X-capable vehicle according to any one of Clauses 39 to 54, the first V2X-capable vehicle further comprising: components for performing driving maneuvers according to the feasible driving trajectory.

[0248] Clause 56. The first V2X-capable vehicle as described in Clause 55, wherein the driving maneuvers include: changing lanes; merging onto a road on which the first V2X-capable vehicle, the second V2X-capable vehicle, or both are driving; an emergency braking event; turning onto another road different from the road on which the first V2X-capable vehicle, the second V2X-capable vehicle, or both are driving; or leaving the road on which the first V2X-capable vehicle, the second V2X-capable vehicle, or both are driving.

[0249] Clause 57. A first V2X-capable vehicle under any one of Clauses 39 to 56, wherein the V2X-capable device is: a second V2X-capable vehicle, a third V2X-capable vehicle, or roadside infrastructure.

[0250] Clause 58. A non-transitory computer-readable medium storing computer-executable instructions, which, when executed by a first vehicle-to-everything (V2X) capable vehicle, cause the first V2X capable vehicle to: receive from a V2X capable device one or more V2X messages indicating an intended driving path of a second V2X capable vehicle; and determine a feasible driving trajectory of the first V2X capable vehicle from a plurality of potential driving trajectories of the first V2X capable vehicle, at least in part based on the intended driving path of the second V2X capable vehicle.

[0251] Clause 59. The non-transitory computer-readable medium according to Clause 58, wherein the computer-executable instructions that, when executed by the first V2X-capable vehicle, cause the first V2X-capable vehicle to determine the feasible driving trajectory, include the following computer-executable instructions: when executed by the first V2X-capable vehicle, cause the first V2X-capable vehicle to: determine an infeasible driving trajectory from the plurality of potential driving trajectories based at least in part on the intended driving path of the second V2X-capable vehicle; and remove the infeasible driving trajectory from the plurality of potential driving trajectories to determine a set of remaining driving trajectories from the plurality of potential driving trajectories, wherein the feasible driving trajectory of the first V2X-capable vehicle is a remaining driving trajectory from the set of remaining driving trajectories.

[0252] Clause 60. The non-transitory computer-readable medium as described in Clause 59 further includes the following computer-executable instructions: when executed by the first V2X-capable vehicle, causing the first V2X-capable vehicle to: send the set of remaining driving trajectories to one or more other V2X-capable vehicles, roadside infrastructure, or any combination thereof; or send the remaining driving trajectories to the one or more other V2X-capable vehicles, the roadside infrastructure, or any combination thereof.

[0253] Clause 61. A non-transitory computer-readable medium according to any one of Clauses 58 to 60, wherein the computer-executable instructions that, when executed by the first V2X-capable vehicle, cause the first V2X-capable vehicle to determine the feasible driving trajectory include the following computer-executable instructions: when executed by the first V2X-capable vehicle, cause the first V2X-capable vehicle to: determine an infeasible driving trajectory among the plurality of potential driving trajectories based at least in part on the intended driving path of the second V2X-capable vehicle; and reallocate nodes from the infeasible driving trajectory to the remaining driving trajectories among the plurality of potential driving trajectories, wherein the feasible driving trajectory of the first V2X-capable vehicle is the remaining driving trajectory among the plurality of potential driving trajectories, wherein each node represents a location on a potential driving trajectory by a macro-action of one or more macro-actions, and wherein each macro-action represents a portion of a lane of a road on which the first V2X-capable vehicle is traveling.

[0254] Clause 62. A non-transitory computer-readable medium according to any one of Clauses 58 to 61, wherein the computer-executable instructions that, when executed by the first V2X-capable vehicle, cause the first V2X-capable vehicle to determine the feasible driving trajectory include the following computer-executable instructions: when executed by the first V2X-capable vehicle, cause the first V2X-capable vehicle to: establish a first search tree of the plurality of potential driving trajectories, wherein each of the plurality of potential driving trajectories corresponds to a subtree of the first search tree.

[0255] Clause 63. The non-transitory computer-readable medium as described in Clause 62, wherein: each subtree of the first search tree includes one or more first macro actions, each first macro action representing a portion of a lane of a road on which the first V2X-capable vehicle, the second V2X-capable vehicle, or both are driving, each first macro action being associated with one or more first nodes, and each first node representing a location on a potential driving trajectory via the portion of the lane of the road represented by the corresponding first macro action.

[0256] Clause 64. The non-transitory computer-readable medium according to Clause 63, wherein: the intended driving path is represented as a subtree of a second search tree of a second V2X-capable vehicle, the subtree of the second search tree comprising one or more second macro-actions, each second macro-action representing a portion of a lane of the road on which the first V2X-capable vehicle, the second V2X-capable vehicle, or both are driving, each second macro-action being associated with one or more second nodes, each second node representing a location within the portion of the lane of the road represented by the corresponding second macro-action.

[0257] Clause 65. The non-transitory computer-readable medium according to Clause 64, wherein the computer-executable instructions that, when executed by the first V2X-capable vehicle, cause the first V2X-capable vehicle to determine the feasible driving trajectory, include the following computer-executable instructions: when executed by the first V2X-capable vehicle, cause the first V2X-capable vehicle to: determine, at least in part, a subtree of a first search tree corresponding to an infeasible driving trajectory among the plurality of potential driving trajectories, based on the subtree representing the intended driving path of the second V2X-capable vehicle; and remove the subtree of the first search tree corresponding to the infeasible driving trajectory from the plurality of potential driving trajectories, wherein the feasible driving trajectory of the first V2X-capable vehicle corresponds to the remaining subtree of the first search tree.

[0258] Clause 66. The non-transitory computer-readable medium as described in Clause 65 further includes the following computer-executable instructions: when executed by the first V2X-capable vehicle, causing the first V2X-capable vehicle to: send the remaining subtree to one or more other V2X-capable vehicles, roadside infrastructure, or any combination thereof.

[0259] Clause 67. The non-transitory computer-readable medium as described in Clause 66, wherein the one or more other V2X-capable vehicles include the second V2X-capable vehicle.

[0260] Clause 68. A non-transitory computer-readable medium according to any one of Clauses 64 to 67, wherein the computer-executable instructions that, when executed by the first V2X-capable vehicle, cause the first V2X-capable vehicle to determine the feasible driving trajectory include the following computer-executable instructions: when executed by the first V2X-capable vehicle, cause the first V2X-capable vehicle to: determine, at least in part, a subtree of a first search tree corresponding to an infeasible driving trajectory among the plurality of potential driving trajectories, based on the subtree representing the intended driving path of the second V2X-capable vehicle; and reallocate nodes from the subtree of the first search tree corresponding to the infeasible driving trajectory to the remaining subtree of the first search tree, wherein the feasible driving trajectory of the first V2X-capable vehicle corresponds to the remaining subtree of the first search tree.

[0261] Clause 69. The non-transitory computer-readable medium as described in Clause 68 further includes the following computer-executable instructions: when executed by the first V2X-capable vehicle, causing the first V2X-capable vehicle to: send the remaining subtree to one or more other V2X-capable vehicles, roadside infrastructure, or any combination thereof.

[0262] Clause 70. A non-transitory computer-readable medium pursuant to any one of Clauses 62 to 69, wherein the first search tree comprises a Monte Carlo tree search.

[0263] Clause 71. A nontransitory computer-readable medium pursuant to any one of Clauses 58 to 70, wherein the one or more V2X messages comprise: one or more Basic Security Messages (BSM), one or more Collective Awareness Messages (CPM), one or more Manipulation Sharing and Coordination Messages (MSCM), one or more Distributed Environment Notification Messages (DENM), or any combination thereof.

[0264] Clause 72. The non-transitory computer-readable medium according to any one of Clauses 58 to 71 further comprises the following computer-executable instructions: when executed by the first V2X-capable vehicle, causing the first V2X-capable vehicle to: send the feasible driving trajectory to at least one or more other V2X-capable vehicles, roadside infrastructure, or any combination thereof; receive one or more driving trajectories from the one or more other V2X-capable vehicles, the roadside infrastructure, or any combination thereof, wherein the feasible driving trajectory is further determined based on the one or more driving trajectories; or any combination thereof.

[0265] Clause 73. The non-transitory computer-readable medium as described in Clause 72, wherein: the feasible driving trajectory is represented as a subtree of a search tree of the first V2X-capable vehicle, the subtree of the search tree comprising one or more macro actions, each macro action representing a portion of a lane of the road on which the first V2X-capable vehicle, the second V2X-capable vehicle, or both are driving, each macro action being associated with one or more nodes, each node representing a location within the portion of the lane of the road represented by the corresponding macro action.

[0266] Clause 74. The non-transitory computer-readable medium according to any one of Clauses 58 to 73, the non-transitory computer-readable medium further comprising the following computer-executable instructions: when executed by the first V2X-capable vehicle, causing the first V2X-capable vehicle to: perform driving maneuvers according to the feasible driving trajectory.

[0267] Clause 75. The non-transitory computer-readable medium as described in Clause 74, wherein the driving maneuver includes: changing lanes; merging onto a road on which the first V2X-capable vehicle, the second V2X-capable vehicle, or both are driving; an emergency braking event; turning onto another road different from the road on which the first V2X-capable vehicle, the second V2X-capable vehicle, or both are driving; or leaving the road on which the first V2X-capable vehicle, the second V2X-capable vehicle, or both are driving.

[0268] Clause 76. The non-transitory computer-readable medium according to any one of Clauses 58 to 75, wherein the V2X-capable device comprises: the second V2X-capable vehicle, the third V2X-capable vehicle, or roadside infrastructure.

[0269] Those skilled in the art will understand that information and signals can be represented using any of a variety of different techniques and methods. For example, data, instructions, commands, information, signals, bits, symbols, and chips that may be mentioned throughout the above description can be represented by voltage, current, electromagnetic waves, magnetic fields or magnetic particles, light fields or optical particles, or any combination thereof.

[0270] Furthermore, those skilled in the art will understand that the various exemplary logic blocks, modules, circuits, and algorithm steps described in connection with the aspects disclosed herein can be implemented as electronic hardware, computer software, or a combination of both. To clearly illustrate this interchangeability between hardware and software, various exemplary components, blocks, modules, circuits, and steps have been described above in general terms of their functionality. Whether such functionality is implemented as hardware or software depends on the specific application and the design constraints imposed on the overall system. Those skilled in the art can implement the described functionality in different ways for each specific application, but such specific implementation decisions should not be construed as departing from the scope of this disclosure.

[0271] The various exemplary logic blocks, modules, and circuits described in conjunction with the aspects disclosed herein may be implemented or performed using a general-purpose processor, a digital signal processor (DSP), an ASIC, a field-programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic components, discrete hardware components, or any combination thereof designed to perform the functions described herein. The general-purpose processor may be a microprocessor, but in alternative embodiments, the processor may be any conventional processor, controller, microcontroller, or state machine. The processor may also be implemented as a combination of computing devices, such as a combination of a DSP and a microprocessor, multiple microprocessors, one or more microprocessors combined with a DSP core, or any other such configuration.

[0272] The methods, sequences, and / or algorithms described in conjunction with the aspects disclosed herein may be embodied directly in hardware, in a software module executed by a processor, or a combination of both. The software module may reside in random access memory (RAM), flash memory, read-only memory (ROM), erasable programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), registers, hard disks, removable disks, CD-ROMs, or any other form of storage medium known in the art. Example storage media are coupled to a processor such that the processor can read information from and write information to the storage medium. Alternatively, the storage medium may be integral with the processor. The processor and storage medium may reside in an ASIC. The ASIC may reside in a user terminal (e.g., a UE). Alternatively, the processor and storage medium may reside as discrete components in the user terminal.

[0273] In one or more examples, the described functionality may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functionality may be stored as one or more instructions or code on or transmitted via a computer-readable medium. A computer-readable medium includes both computer storage media and communication media, which includes any medium that facilitates the transfer of a computer program from one place to another. A storage medium may be any available medium accessible to a computer. By way of example and not limitation, such computer-readable media may include RAM, ROM, EEPROM, CD-ROM or other optical disc storage, disk storage or other magnetic storage devices, or any other medium that can be used to carry or store the desired program code in the form of instructions or data structures and is accessible to a computer. Furthermore, any connection is appropriately referred to as a computer-readable medium. For example, if the software is transmitted from a website, server, or other remote source using coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared, radio, and microwave, then coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included within the definition of a medium. As used herein, disks and optical discs include: compact optical discs (CDs), laser discs, optical discs, digital versatile discs (DVDs), floppy disks, and Blu-ray discs. Disks typically reproduce data magnetically, while optical discs reproduce data optically using lasers. Combinations of these should also be included within the scope of computer-readable media.

[0274] While the foregoing disclosure illustrates exemplary aspects of this disclosure, it should be noted that various changes and modifications may be made herein without departing from the scope of this disclosure as defined by the appended claims. For example, the functions, steps, and / or actions of the method claims according to aspects of this disclosure described herein need not be performed in any particular order. Furthermore, no component, function, action, or instruction described or claimed herein should be construed as critical or essential unless explicitly stated otherwise. Additionally, as used herein, the terms “set,” “group,” etc., are intended to include one or more of the stated elements. Furthermore, as used herein, the terms “having,” “comprising,” “including,” etc., do not exclude the presence of one or more additional elements (e.g., element “having” A may also have B). Furthermore, the phrase “based on” is intended to mean “at least partially based on” unless otherwise explicitly stated. Furthermore, as used herein, the term “or” is intended to be open-ended when used in a series and is interchangeable with “and / or” unless otherwise expressly stated (e.g., if used in conjunction with “any” or “only one”), or these alternatives are mutually exclusive (e.g., “one or more” should not be interpreted as “one and more”). Additionally, although components, functions, actions, and instructions may be described or claimed in the singular, plural forms may also be considered unless expressly stated as limited to the singular. Therefore, as used herein, the articles “a,” “an,” “the,” and “the” are intended to include one or more of the described elements. Additionally, as used herein, the terms “at least one” and “one or more” include “one” component, function, action, or instruction that performs or is capable of performing the described or claimed functionality, and also include “two or more” components, functions, actions, or instructions that perform or are capable of performing the described or claimed functionality in combination.

Claims

1. A method for wireless communication performed by a first vehicle-to-everything (V2X) capable vehicle, the method comprising: Receive one or more V2X messages from a V2X-capable device that indicate the intended driving route of a second V2X-capable vehicle; as well as The feasible driving trajectory of the first V2X-capable vehicle is determined from multiple potential driving trajectories of the first V2X-capable vehicle, based at least in part on the intended driving path of the second V2X-capable vehicle.

2. The method of claim 1, wherein determining the feasible driving trajectory comprises: The infeasible driving trajectory among the plurality of potential driving trajectories is determined at least in part based on the intended driving path of the second V2X-capable vehicle; as well as The infeasible driving trajectory is removed from the plurality of potential driving trajectories to determine a set of remaining driving trajectories from the plurality of potential driving trajectories, wherein the feasible driving trajectory of the first V2X-capable vehicle is a remaining driving trajectory from the set of remaining driving trajectories.

3. The method according to claim 2, further comprising: Send the set of remaining driving trajectories to one or more other V2X-capable vehicles, roadside infrastructure, or any combination thereof; or The remaining driving trajectory is sent to one or more other V2X-capable vehicles, the roadside infrastructure, or any combination thereof.

4. The method of claim 1, wherein determining the feasible driving trajectory comprises: The infeasible driving trajectory among the plurality of potential driving trajectories is determined at least in part based on the intended driving path of the second V2X-capable vehicle; as well as The nodes are reassigned from the infeasible driving trajectories to the remaining driving trajectories among the multiple potential driving trajectories. The feasible driving trajectory of the first V2X-capable vehicle is the remaining driving trajectory among the plurality of potential driving trajectories. Each node represents the location on the potential driving trajectory through one or more macro actions, and Each macro action represents a portion of the lane on the road on which the first V2X-capable vehicle is traveling.

5. The method of claim 1, wherein determining the feasible driving trajectory comprises: A first search tree is established for the plurality of potential driving trajectories, wherein each of the plurality of potential driving trajectories corresponds to a subtree of the first search tree.

6. The method according to claim 5, wherein: Each subtree of the first search tree includes one or more first macro actions. Each first macro action represents a portion of the lane on the road on which the first V2X-capable vehicle, the second V2X-capable vehicle, or both are driving. Each first macro action is associated with one or more first nodes, and Each first node represents a location on a potential driving trajectory via a portion of the lane of the road represented by the corresponding first macro action.

7. The method according to claim 6, wherein: The intended driving path is represented as a subtree of the second search tree of the second V2X-capable vehicle. The subtree of the second search tree includes one or more second macro actions. Each second macro action represents a portion of the lane of the road on which the first V2X-capable vehicle, the second V2X-capable vehicle, or both are driving. Each second macro action is associated with one or more second nodes. Each second node represents a location within the portion of the lane of the road represented by the corresponding second macro action.

8. The method of claim 7, wherein determining the feasible driving trajectory comprises: The subtree of the first search tree corresponding to the infeasible driving trajectory among the plurality of potential driving trajectories is determined at least in part based on the subtree representing the intended driving path of the second V2X-capable vehicle; as well as Remove the subtree of the first search tree corresponding to the infeasible driving trajectory from the plurality of potential driving trajectories, wherein the feasible driving trajectory of the first V2X-capable vehicle corresponds to the remaining subtree of the first search tree.

9. The method according to claim 8, further comprising: Send the remaining subtree to one or more other V2X-capable vehicles, roadside infrastructure, or any combination thereof.

10. The method of claim 9, wherein the one or more other V2X-capable vehicles include the second V2X-capable vehicle.

11. The method of claim 7, wherein determining the feasible driving trajectory comprises: The subtree of the first search tree corresponding to the infeasible driving trajectory among the plurality of potential driving trajectories is determined at least in part based on the subtree representing the intended driving path of the second V2X-capable vehicle; as well as The node is reassigned from the subtree of the first search tree corresponding to the infeasible driving trajectory to the remaining subtree of the first search tree, wherein the feasible driving trajectory of the first V2X-capable vehicle corresponds to the remaining subtree of the first search tree.

12. The method according to claim 11, further comprising: Send the remaining subtree to one or more other V2X-capable vehicles, roadside infrastructure, or any combination thereof.

13. The method of claim 5, wherein the first search tree comprises a Monte Carlo tree search.

14. The method of claim 1, wherein the one or more V2X messages comprise: One or more Basic Security Messages (BSMs). One or more collectively perceived messages (CPM). One or more manipulation sharing and coordination messages (MSCM). One or more distributed environment notification messages (DENM), or Any combination of them.

15. The method according to claim 1, further comprising: The feasible driving trajectory shall be sent to at least one or more other vehicles with V2X capabilities, roadside infrastructure, or any combination thereof; Receive one or more driving trajectories from the one or more other V2X-capable vehicles, the roadside infrastructure, or any combination thereof, wherein the feasible driving trajectory is further determined based on the one or more driving trajectories; or Any combination of them.

16. The method of claim 15, wherein: The feasible driving trajectory is represented as a subtree of the search tree of the first V2X-capable vehicle. The subtrees of the search tree include one or more macro actions. Each macro action represents a portion of the lane of the road on which the first V2X-capable vehicle, the second V2X-capable vehicle, or both are driving. Each macro action is associated with one or more nodes. Each node represents a location within a portion of the lane of the road represented by the corresponding macro-action.

17. The method according to claim 1, further comprising: Perform driving maneuvers according to the described feasible driving trajectory.

18. The method of claim 17, wherein the driving operation comprises: Change lanes, Merging onto the road on which the first V2X-capable vehicle, the second V2X-capable vehicle, or both are driving, Emergency braking incident, Turn onto another road that is different from the road on which the first V2X-capable vehicle, the second V2X-capable vehicle, or both are driving, or From the road on which the first V2X-capable vehicle, the second V2X-capable vehicle, or both are driving.

19. The method of claim 1, wherein the V2X-capable device is: The second type of vehicle with V2X capability, The third type of vehicle with V2X capability, or Roadside infrastructure.

20. A first vehicle-to-everything (V2X) capable vehicle, the first vehicle-to-everything (V2X) capable vehicle comprising: One or more memory units; One or more transceivers; and One or more processors, communicatively coupled to one or more memories and one or more transceivers, wherein the one or more processors are configured individually or in combination to: Receive one or more V2X messages from a V2X-capable device via the one or more transceivers, indicating the intended driving route of a second V2X-capable vehicle; as well as The feasible driving trajectory of the first V2X-capable vehicle is determined from multiple potential driving trajectories of the first V2X-capable vehicle, based at least in part on the intended driving path of the second V2X-capable vehicle.

21. The first V2X-capable vehicle of claim 20, wherein the one or more processors are configured to determine the feasible driving trajectory, including the one or more processors being configured individually or in combination to: The infeasible driving trajectory among the plurality of potential driving trajectories is determined at least in part based on the intended driving path of the second V2X-capable vehicle; and The infeasible driving trajectory is removed from the plurality of potential driving trajectories to determine a set of remaining driving trajectories from the plurality of potential driving trajectories, wherein the feasible driving trajectory of the first V2X-capable vehicle is a remaining driving trajectory from the set of remaining driving trajectories.

22. The first V2X-capable vehicle of claim 21, wherein the one or more processors are further configured individually or in combination to: The remaining driving trajectories are transmitted via the one or more transceivers to one or more other V2X-capable vehicles, roadside infrastructure, or any combination thereof; or The remaining driving trajectory is transmitted via the one or more transceivers to the one or more other V2X-capable vehicles, the roadside infrastructure, or any combination thereof.

23. The first V2X-capable vehicle of claim 20, wherein the one or more processors are configured to determine the feasible driving trajectory, including the one or more processors being configured individually or in combination to: The infeasible driving trajectory among the plurality of potential driving trajectories is determined at least in part based on the intended driving path of the second V2X-capable vehicle; and The nodes are reassigned from the infeasible driving trajectories to the remaining driving trajectories among the multiple potential driving trajectories. The feasible driving trajectory of the first V2X-capable vehicle is the remaining driving trajectory among the plurality of potential driving trajectories. Each node represents the location on the potential driving trajectory through one or more macro actions, and Each macro action represents a portion of the lane on the road on which the first V2X-capable vehicle is traveling.

24. The first V2X-capable vehicle of claim 20, wherein the one or more processors are configured to determine the feasible driving trajectory, wherein the one or more processors are individually or in combination configured to: A first search tree is established for the plurality of potential driving trajectories, wherein each of the plurality of potential driving trajectories corresponds to a subtree of the first search tree.

25. The first V2X-capable vehicle according to claim 24, wherein: Each subtree of the first search tree includes one or more first macro actions. Each first macro action represents a portion of the lane on the road on which the first V2X-capable vehicle, the second V2X-capable vehicle, or both are driving. Each first macro action is associated with one or more first nodes, and Each first node represents a location on a potential driving trajectory via a portion of the lane of the road represented by the corresponding first macro action.

26. The first V2X-capable vehicle according to claim 25, wherein: The intended driving path is represented as a subtree of the second search tree of the second V2X-capable vehicle. The subtree of the second search tree includes one or more second macro actions. Each second macro action represents a portion of the lane of the road on which the first V2X-capable vehicle, the second V2X-capable vehicle, or both are driving. Each second macro action is associated with one or more second nodes. Each second node represents a location within the portion of the lane of the road represented by the corresponding second macro action.

27. The first V2X-capable vehicle of claim 26, wherein the one or more processors are configured to determine the feasible driving trajectory, wherein the one or more processors are individually or in combination configured to: The subtree of the first search tree corresponding to the infeasible driving trajectory among the plurality of potential driving trajectories is determined at least in part based on the subtree representing the intended driving path of the second V2X-capable vehicle; and Remove the subtree of the first search tree corresponding to the infeasible driving trajectory from the plurality of potential driving trajectories, wherein the feasible driving trajectory of the first V2X-capable vehicle corresponds to the remaining subtree of the first search tree.

28. The first V2X-capable vehicle of claim 27, wherein the one or more processors are further configured individually or in combination to: The remaining subtree is transmitted via the one or more transceivers to one or more other V2X-capable vehicles, roadside infrastructure, or any combination thereof.

29. The first V2X-capable vehicle of claim 28, wherein the one or more other V2X-capable vehicles include the second V2X-capable vehicle.

30. The first V2X-capable vehicle of claim 26, wherein the one or more processors are configured to determine the feasible driving trajectory, including the one or more processors being configured individually or in combination to: The subtree of the first search tree corresponding to the infeasible driving trajectory among the plurality of potential driving trajectories is determined at least in part based on the subtree representing the intended driving path of the second V2X-capable vehicle; and The node is reassigned from the subtree of the first search tree corresponding to the infeasible driving trajectory to the remaining subtree of the first search tree, wherein the feasible driving trajectory of the first V2X-capable vehicle corresponds to the remaining subtree of the first search tree.

31. The first V2X-capable vehicle according to claim 30, wherein the one or more processors are further configured individually or in combination to: The remaining subtree is transmitted via the one or more transceivers to one or more other V2X-capable vehicles, roadside infrastructure, or any combination thereof.

32. The first V2X-capable vehicle of claim 24, wherein the first search tree comprises a Monte Carlo tree search.

33. The first V2X-capable vehicle according to claim 20, wherein the one or more V2X messages include: One or more Basic Security Messages (BSMs). One or more collectively perceived messages (CPM). One or more manipulation sharing and coordination messages (MSCM). One or more distributed environment notification messages (DENM), or Any combination of them.

34. The first V2X-capable vehicle of claim 20, wherein the one or more processors are further configured individually or in combination to: The feasible driving trajectory is transmitted via the one or more transceivers to at least one or more other V2X-capable vehicles, roadside infrastructure, or any combination thereof; Receive one or more driving trajectories from one or more other V2X-capable vehicles, the roadside infrastructure, or any combination thereof via the one or more transceivers, wherein the feasible driving trajectory is further determined based on the one or more driving trajectories; or Any combination of them.

35. The first V2X-capable vehicle according to claim 34, wherein: The feasible driving trajectory is represented as a subtree of the search tree of the first V2X-capable vehicle. The subtrees of the search tree include one or more macro actions. Each macro action represents a portion of the lane of the road on which the first V2X-capable vehicle, the second V2X-capable vehicle, or both are driving. Each macro action is associated with one or more nodes. Each node represents a location within a portion of the lane of the road represented by the corresponding macro-action.

36. The first V2X-capable vehicle of claim 20, wherein the one or more processors are further configured individually or in combination to: Perform driving maneuvers according to the described feasible driving trajectory.

37. The first V2X-capable vehicle according to claim 36, wherein the driving controls include: Change lanes, Merging onto the road on which the first V2X-capable vehicle, the second V2X-capable vehicle, or both are driving, Emergency braking incident, Turn onto another road that is different from the road on which the first V2X-capable vehicle, the second V2X-capable vehicle, or both are driving, or From the road on which the first V2X-capable vehicle, the second V2X-capable vehicle, or both are driving.

38. The first V2X-capable vehicle according to claim 20, wherein the V2X-capable device is: The second type of vehicle with V2X capability, The third type of vehicle with V2X capability, or Roadside infrastructure.

39. A first vehicle-to-everything (V2X) capable vehicle, the first vehicle-to-everything (V2X) capable vehicle comprising: Component for receiving one or more V2X messages from a V2X-capable device that indicate the intended driving route of a second V2X-capable vehicle; and Components for determining a feasible driving trajectory of the first V2X-capable vehicle from a plurality of potential driving trajectories of the first V2X-capable vehicle, based at least in part on the intended driving path of the second V2X-capable vehicle.

40. A non-transitory computer-readable medium storing computer-executable instructions, said computer-executable instructions, when executed by a first vehicle-to-everything (V2X) capable vehicle, causing the first V2X capable vehicle to: Receive one or more V2X messages from a V2X-capable device indicating the intended driving route of a second V2X-capable vehicle; and The feasible driving trajectory of the first V2X-capable vehicle is determined from multiple potential driving trajectories of the first V2X-capable vehicle, based at least in part on the intended driving path of the second V2X-capable vehicle.

Images