C-V2X Message Processing Timeline Adaptation Based on the Outline of a Remote Vehicle and the Available Delay Budget

Abstract

The techniques described herein provide filtering and prioritization of incoming messages, which can help reduce and smooth the processing load on components used to process incoming messages. The filtering techniques can include identifying a subset of nearby vehicles such that messages from that subset will be processed, and further calculating a remaining latency budget for messages to prioritize them for processing. Different techniques for determining the subset of nearby vehicles can be used, and / or the remaining latency budget can be calculated and / or communicated in different ways.

Description

[0001] Priority Claim

[0002] This application claims the priority and benefit of U.S. Non - Provisional Patent Application S / N. 16 / 797,674, filed on February 21, 2020, entitled "C - V2X MESSAGE PROCESSING TIMELINE ADAPTION BASED ON CONTOURING OF REMOTE VEHICLES AND AND AVAILABLE DELAY BUDGET", which is hereby incorporated by reference in its entirety.

[0003] Background

[0004] Autonomous or semi - autonomous vehicles can communicate with nearby vehicles regularly to enhance the safety, efficiency, and convenience of vehicle transportation. For example, path and maneuver planning for vehicles with vehicle - to - everything (V2X) capabilities (such as cellular vehicle - to - everything (CV2X) vehicles) depends on knowing the accurate inter - vehicle distances and relative positions. The capabilities and behaviors of surrounding vehicles help determine, for example, safe inter - vehicle gaps and lane - change maneuvers. Location and location - related measurements are communicated regularly between vehicles, e.g., using messages such as basic safety messages (BSM) via V2X application - layer standards. However, these messages can be broadcast from vehicles at a rate of several times per second, and thus a V2X - capable vehicle surrounded by a large number of V2X - capable vehicles can receive a very large number of messages to process. Additionally, some messages may have a higher priority and may need to be attended to more quickly than others, and various operational constraints can further alter the ability of a V2X - capable vehicle to process incoming messages.

[0005] Brief Summary

[0006] The techniques described herein provide filtering and prioritization of incoming messages, which can help reduce and smooth the processing load on components used to process incoming messages. Filtering techniques can include identifying a subset of nearby vehicles to process messages from that subset, and further calculating a remaining delay budget for messages to prioritize them for processing. Different techniques for classifying nearby vehicles and determining a subset of nearby vehicles can be used, and different techniques for calculating and / or communicating the delay budget can be used.

[0007] An example method for message selection and prioritization at a host vehicle (HV) according to this specification includes: wirelessly receiving messages from a plurality of remote vehicles (RVs); determining a first subset of the plurality of RVs to process messages from the first subset, wherein the first subset is determined at least in part based on: the respective positions of each RV relative to the HV, one or more road conditions, and one or more operating constraints of the HV. The method further includes, for each message received from an RV in the first subset, determining a priority for the respective message at least in part based on an indication of a remaining delay budget for the respective message, wherein the priority for the respective message determines the order in which the content of the respective message will be processed by the HV, and the indication of the remaining delay budget for the respective message is received with the respective message.

[0008] An example apparatus for message selection and prioritization at a host vehicle (HV) according to this specification includes one or more wireless transceivers, a memory, and one or more processors communicatively coupled to the one or more wireless transceivers and the memory. The one or more processors are configured to: receive messages from a plurality of remote vehicles (RVs) via the one or more wireless transceivers; and determine a first subset of the plurality of RVs to process messages from the first subset, wherein the first subset is determined at least in part based on: the respective positions of each RV relative to the HV, one or more road conditions, and one or more operating constraints of the HV. The one or more processors are further configured to: for each message received from an RV in the first subset, determine a priority for the respective message at least in part based on an indication of a remaining delay budget for the respective message, wherein the priority for the respective message determines the order in which the content of the respective message will be processed by the HV, and the indication of the remaining delay budget for the respective message is received with the respective message.

[0009] An example apparatus according to this specification includes: means for wirelessly receiving messages from a plurality of remote vehicles (RVs); and means for determining a first subset of the plurality of RVs to process messages from the first subset, wherein the first subset is determined at least in part based on: the respective positions of each RV relative to a host vehicle (HV), one or more road conditions, and one or more operating constraints of the HV. The apparatus further includes: means for determining a priority for each message received from an RV in the first subset at least in part based on an indication of a remaining delay budget for the respective message, wherein the priority for the respective message determines the order in which the content of the respective message will be processed by the HV, and the indication of the remaining delay budget for the respective message is received with the respective message.

[0010] An example non-transitory computer-readable medium according to this specification includes instructions stored thereon for message selection and prioritization at a host vehicle (HV). When executed by one or more processors, these instructions cause the one or more processors to: wirelessly receive messages from a plurality of remote vehicles (RVs); and determine a first subset of the plurality of RVs to process messages from the first subset, wherein the first subset is determined at least in part based on: the respective positions of each RV relative to the HV, one or more road conditions, and one or more operating constraints of the HV. When executed by one or more processors, these instructions further cause the one or more processors to: for each message received from an RV in the first subset, determine a priority for the respective message at least in part based on an indication of a remaining delay budget for the respective message, wherein: the priority for the respective message determines the order in which the content of the respective message will be processed by the HV, and the indication of the remaining delay budget for the respective message is received with the respective message. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] Figure 1 is a top view of a road according to one embodiment, provided to assist in explaining how vehicles can be classified and how zones of interest can be established.

[0013] Figure 2A 、 2B and 3 are illustrations of top views of Figure 1 to which different profiles are applied according to one embodiment.

[0014] Figure 4A and 4B are flowcharts illustrating methods for creating zones of interest for filtering messages from incoming vehicles according to some embodiments.

[0015] Figure 5 is a simplified block diagram of relevant communication components of a vehicle according to one embodiment, provided to assist in explaining the functionality of different components for message prioritization.

[0016] Figure 6 is an illustration according to one embodiment of Figure 5 the call flow diagram of the functionality and communication between the various components illustrated in

[0017] Figure 7 is a flowchart of a method for message selection and prioritization at a vehicle according to one embodiment.

[0018] Figure 8Explanation of a system in accordance with one embodiment in which a vehicle can communicate on various networks and with various devices, vehicles, and servers.

[0019] Figure 9 Functional block diagram of a vehicle 1000 in accordance with one embodiment.

[0020] Figure 10 Block diagram of various hardware and software components of a vehicle in accordance with one embodiment.

[0021] Figure 11 Perspective view of an exemplary vehicle 1000 in accordance with one embodiment.

[0022] Like reference numerals in the various figures indicate like elements in accordance with certain example implementations. Additionally, multiple instances of an element may be indicated by appending a letter or hyphen and a second number to the first number of the element. For example, multiple instances of element 110 may be indicated as 110-1, 110-2, 110-3, etc. or as 110a, 110b, 110c, etc. When only the first number is used to refer to such an element, it will be understood to refer to any instance of the element (e.g., element 110 in the previous example will refer to elements 110-1, 110-2, and 110-3 or elements 110a, 110b, and 110c).

[0023] Detailed Description

[0024] Certain illustrative embodiments will now be described with reference to the accompanying drawings that form a part of the embodiments. Although specific embodiments in which one or more aspects of the present disclosure may be implemented are described below, other embodiments may be used and various modifications may be made without departing from the scope of the present disclosure or the spirit of the appended claims.

[0025] A vehicle with V2X capabilities can execute vehicle-to-vehicle (V2V) safety applications built around the Society of Automotive Engineers (SAE) J2735 BSM, which conveys information about vehicle position, time, heading, speed, acceleration, predicted path, path history, and more. As mentioned, this information can be used by nearby vehicles to inform the movement and maneuver execution of a vehicle. As mentioned, a given V2X-capable vehicle of interest (referred to herein as the host vehicle (HV)) can receive a large number of BSMs broadcast by nearby V2X-capable vehicles (referred to herein as remote vehicles (RVs)) within the communication range. For example, BSMs can be broadcast up to 10 times per second (10 Hz). And thus, if the HV is surrounded by 200 RVs each conveying up to 10 BSMs per second, the HV may need to process up to 2000 BSMs per second. This processing can include verifying the digital signature certificate of the message and determining whether to issue a warning to the driver, make a change, or execute a maneuver, etc. based on the content of the message. Additionally, additional message types (e.g., non-BSM safety messages) can also be communicated from nearby RVs to the HV, and other communications can be received from roadside units (RSUs), traffic-related servers, etc. Further, the information conveyed by BSMs and other messages is typically very time-sensitive and must be quickly processed by the HV before it becomes irrelevant. Thus, the HV typically has limited ability to delay the processing of these incoming messages. This can result in a high processing load on the hardware blocks of the HV (e.g., central processing unit (CPU), digital signal processor (DSP), and / or elliptic curve digital signature algorithm (ECDSA)).

[0026] Traditional techniques for handling these problems have their drawbacks. For example, to avoid any security compromise, current solutions are designed to operate at the performance level of the worst case scenario (e.g., the maximum number of messages). To provide sufficient processing power to do so, this can be an expensive option in terms of price, power, and / or temperature. Additionally, traditional techniques typically only account for the packet delay budget allocated at the radio layer of the transmitting RV and the receiving HV, without accounting for the total end-to-end packet delay from the application layer of the transmitting RV to the application layer of the receiving HV. This can mean that although the radio layer delay budget is met, the message may not be processed in time to meet the application layer needs. To overcome this problem, traditional techniques again use brute force techniques, by operating the radio layer hardware (modem) at a very high operating frequency to always account for the worst case scenario, without accounting for the variability of the messages from the RVs.

[0027] The embodiments provided herein can solve these and other problems in the following ways: by establishing a zone of interest to identify which RVs' messages will be processed so that the HV can filter incoming messages from the RVs, and further prioritizing the filtered messages at the application layer based on the remaining time budget to smooth the processing load demand over time. The zone of interest can be defined based on multiple factors, including the relative positions of the RVs, one or more road conditions, and one or more vehicle operating conditions. Additional details are provided below with respect to the drawings.

[0028] Figure 1 is a top view of road 100, which is provided to help illustrate how RVs can be classified and how a zone of interest can be established. Figure 1 Shows multiple vehicles on road 100, including HV 110 surrounded by multiple RVs (collectively and generally referred to herein as RV 130). As can be seen, the trajectories of RV 130 can be classified as traveling in the same direction as or opposite (reverse) to the HV. Additionally, according to some embodiments, as illustrated by line 120 shown in Figure 1 Based on the orientation of HV 110, the position of RV 130 can be classified as "in front of" or "behind" HV 110. (However, it will be understood that alternative embodiments may position line 120 differently relative to HV 110, such as more towards the front of HV 110 or more towards the rear of HV 110. Additionally or alternatively, embodiments may classify the vehicle as in front of or behind HV 110, but "adjacent" to HV 110, as indicated below.)

[0029] For the purposes of the description herein, labels can be used to describe the position and trajectory of RV 130 relative to HV 110. Table 1 provides the Figure 1 mapping of the RVs illustrated in to the labels used herein and a description of the label.

[0030]

[0031]

[0032] Table 1: RV Labels Applied to Figure 1 the

[0033] As can be seen in Table 1, the markings take into account the direction and position of the RV 130 around the HV 110. As previously mentioned, additional markings can be used to account for RVs 130 that are not completely in front of or completely behind the HV 110. For example, the line 120 passes through the RV 130-7, in which case it can be considered "adjacent". RVs (not shown) in other lanes that are also not completely in front of or completely behind the HV 110 can be classified similarly. That is, based on the information received by the HV 110 about the position of the RV 130-7 (e.g., via a BSM received from the RV 130-7), the HV 110 can determine whether to classify the RV 130-7 as in front of or behind the HV 110 based on a certain position on the RV 130-7 (e.g., the front, center, or rear of the vehicle).

[0034] In an earlier example where the HV 110 is surrounded by 200 vehicles, BSMs or similar messages from many other vehicles may be irrelevant to the safety or operation of the HV 110. Taking this into account, and again referring to Figure 1 the example shown in, the HV 110 can create one or more "profiles" that define one or more regions of interest surrounding a group of RVs 130. These profiles can specifically exclude RVs 130 from which messages may be irrelevant. For example, messages from the RVs 130-9 and 130-11 traveling in the opposite direction of the HV 110 and behind the HV 110 can be excluded from these regions of interest. Many other factors can be considered when determining the profiles that define the regions of interest.

[0035] Figure 2A and 2B are top views of the road 100 with two different profiles 210-A and 210-B (collectively and generally referred to herein as profile 210). As illustrated, the profile 210 defines the region in which a subset of adjacent RVs are located. Figure 1 The examples provided in Figure 2A and 2B show relatively simple profiles, but it will be understood that the profiles can be more complex in real-life scenarios. For example, the profiles can be three-dimensional to account for underpasses or overpasses near the HV 110. Further, the profile 210 can be determined by the application layer of the HV 110, which can be executed by one or more processors (described in more detail below).

[0036] The shape of the profile 210 can be based on any of a variety of factors related to the current traffic conditions of the HV 110. These factors, referred to herein as "road conditions", can include, for example, the speed and / or heading of the HV 110, the number of lanes of the road 100, the current lane in which the HV 110 is located, road hazards, weather-related conditions (rain, snow, ice, etc.), speed limits, the path history and / or predicted path of the RV 130, etc. This information can be collected via sensors on the HV 110, V2X and / or other communications with the RV 130, communications with computer servers that provide, for example, map-related, weather-related, and / or other traffic-related information, etc. (Additional relevant details are described below with respect to Figure 8 are described.)

[0037] Additionally, the shape of the profile 210 can be based on one or more constraints due to the processing capabilities of the HV 110. These constraints, referred to herein as "operational constraints", can include, for example, constraints in the message processing capabilities of the HV 110, which may be due to static and / or dynamic characteristics of the underlying hardware and / or software used by the HV 110 to process messages. (Examples of hardware and software components for processing messages are provided below with respect to Figure 10 are provided.)

[0038] Another operational constraint can include thermal constraints, which can also limit the amount of messages processed. That is, given the on-chip temperature of the processor and / or other digital processing hardware used to process messages, and / or the external temperature of the HV 110, the processing of messages can be reduced (e.g., via a reduction in the operating clock frequency) to help ensure that the thermal maximum is not exceeded, in an effort to ensure the operational integrity of the processing hardware.

[0039] Another operational constraint can include concurrency constraints related to the ability of the HV 110 to participate in concurrent operations that utilize the same underlying hardware and / or software components for processing messages. That is, the communication components for sending and receiving V2X messages can include components that implement cellular communications (such as communications via Long Term Evolution (LTE) or Fifth Generation (5G)). Accordingly, these components can also be used for data, voice, emergency (e.g., eCall), and / or other communications. Since the components of the HV 110 can participate in such alternative forms of communication (or can retain a certain amount of capacity to enable participation in such alternative forms of communication), this can operate as a constraint, thereby limiting the amount of messages that the HV 110 can process within a given period of time.

[0040] Returning to the markings shown in Table 1, the profile 210 can be defined by the number of RVs 130 of different RV types included within the region of interest. For example, depending on various road conditions and / or operational constraints, each of the various parameters (Nsa, Nsb, Naa, etc.) corresponding to different types of RVs 130 can be "tuned" to include a greater or lesser amount of that type of RV 130. This "tuning" can be distance-based such that an increase in a particular parameter can cause the profile 210 to expand to include additional RVs 130 of the same type but further away from the HV 110. For example, in Figure 2A In the example of, the value of the term Nsa is 1. That is, only one RV 130-1 is traveling in the same lane as the HV 110 in the same direction and is in front of the HV 110. An increase in the value of the term Nsa can cause the profile 210-A to encompass additional HVs (not shown) traveling in the same direction in the same lane as the HV 110 and in front of the HV 110. As the value of the term Nsa increases, the distance of the profile 210-A in front of the HV 110 also increases to encompass this additional HV.

[0041] This tuning of the parameter is shown in the difference in the profile 210 in Figure 2A and 2B . In Figure 2B , the corresponding profile 210-B encompasses a smaller region of interest than the profile 210-A of FIG. A. Again, this may be due to one or more of the various road conditions and / or operational constraints. The profile 210-A of Figure 2A defining the larger region of interest may be due to the HV 110 having relatively fewer operational constraints (less restrictions on message handling capabilities). Additionally or alternatively, the relatively large region of interest may be due to road conditions that warrant a larger region of interest, such as hazardous weather conditions (e.g., icy roads), the HV 110 traveling at a relatively high speed, a large number of RVs 130 within a relatively short distance of the HV 110, curves in the road 100, etc. On the other hand, the profile 210-B of Figure 2B defining the smaller region of interest may be due to the HV 110 having relatively more operational constraints (more restrictions on message handling capabilities) and / or having road conditions that warrant a smaller region of interest (such as a dry road, low speed, etc.).

[0042] Some embodiments may account for operational constraints and road conditions in different ways. For example, in some embodiments, the HV 110 may use a two-step approach: first determine (e.g., at the application layer) multiple profiles 210 based on various road conditions and then select from these profiles based on operational constraints. This process is illustrated in Figure 3 .

[0043] Figure 3is a plurality of profiles 210 - 1 , 210 - 2 and 210 - 3 as determined by HV 110 Figure 1 The profiles may be ordered such that the largest profile 210-1 corresponds to a "first order" profile, the second largest profile 210-2 corresponds to a "second order" profile, and the third largest profile 210-3 corresponds to a "third order" profile. As will be appreciated, the HV 110 may calculate any number of profiles 210.

[0044] Again, using the notation of Table 1, a profile of order "i" may define the value of each parameter type as Nsai, Naai, Nnai, etc. A higher order profile has a smaller region of interest than a lower order profile and covers fewer RVs 130 than a lower order profile. Thus, where the first order parameters are defined as Nsa1, Naa1, Nna1, etc., and the second order parameters are defined as Nsa2, Naa2, Nna2, etc., each second order parameter is equal to or less than a corresponding parameter in the first order parameters such that Nsa2≤Nsa1, Naa2≤Naa1, Nna2≤Nna1, etc., where at least one parameter in the second order is less than a corresponding parameter in the first order.

[0045] Figure 3 The profile 210 may be created based on the previously mentioned road conditions and some logic for reducing the region of interest for the higher order profile. For example, under the assumption that the operating constraints are minimal, the initial profile 210-1 may be created based on the road conditions. Logic may then be applied to reduce the values of some or all parameters (e.g., reduce the number of covered RVs 130 by one or more) to create a second order profile 210-2. The logic may then be applied again to reduce the values of some or all parameters of the second order profile 210-2 to create a third order profile 210-3, and so on.

[0046] Once the profile 210 is created, the HV 110 may then select the profile 210 to use based on the operating constraints. For example, if the operating constraints are relatively minimal, then a relatively low-order profile may be selected. On the other hand, if the operating constraints are restrictive, then a relatively high-order profile may be selected.

[0047] Figure 4A and 4B is a flow chart illustrating a method 400 for creating a region of interest for use in filtering messages from an incoming RV 130, outlining the previously described Figure 2A-3 The HV 110 may repeat either or both of the methods 400 to continuously define profiles 210 that may be used to perform message filtering. An apparatus for performing these methods may include one or more hardware and / or software components of the HV 110, such as those described below. Figure 10 Those explained in .

[0048] For example, Figure 4A method 400-A shown in Figure 3 illustrates the two-step method previously described with respect to where a profile is defined based on road conditions (and other logic), and subsequently a profile is selected based on operating constraints. Specifically, the functionality of block 410 includes obtaining road conditions. Again, this can be obtained from sensors, RV 130, the server, and / or other devices communicatively coupled to HV 110.

[0049] As shown in block 420, a profile 210 is subsequently determined based on the obtained road conditions and additional logic. The higher-order profile 210 can be defined by reducing the number of one or more types of RV 130 (e.g., the parameters of Table 1) at each increment. Depending on the desired functionality, HV 110 can determine any number of profiles 210, which can be fixed or dynamic depending on the desired functionality.

[0050] As shown in block 430, operating constraints are subsequently obtained. As mentioned, this can include comparing the on-chip temperature and / or ambient temperature to temperature thresholds of HV 110, evaluating the message handling capabilities of HV 110, and / or determining whether processing resources are being shared with other processes (e.g., cellular data / voice communication). A profile 210 is then selected based on the operating constraints, as shown in block 440.

[0051] The functionality shown in block 450 includes identifying RVs 130 within the area of interest defined by profile 210. Again, this can be based on location, identity, and / or other information obtained directly from RV 130, and / or information from other sources. Method 400-A can then continue to process messages from the identified RVs while ignoring messages from other RVs. As mentioned, filtering messages in this way can result in a significant reduction in processing load by ignoring messages not relevant to HV 110 (e.g., BSM).

[0052] In some embodiments, ignoring messages from RVs 130 outside the area of interest can be performed through a combination of the functionality of the application layer and radio layer of HV 110 (which will be described in more detail below). In some embodiments, for example, the application layer can perform the functionality at block 450 by identifying RVs 130 within the area of interest, and then indicating the identities of the identified RVs to the radio layer so that the radio layer can filter incoming messages accordingly. In some embodiments, for example, the application layer can provide the L2 addresses of the messages to be considered to the radio layer (although this may be limited and in fact these addresses can change over time).

[0053] Method 400-B shows previously with respect to Figure 2A and 2BThe single-step method under discussion, wherein Figure 4A the functions shown in blocks 410 and 430 (obtaining road conditions and operating constraints, respectively) are performed together, and as shown in block 470, a single profile is determined based on both the road conditions and the operating constraints. Method 400-B can then proceed in a manner similar to method 400-A to identify RVs in the area of interest (at block 450) and process messages from those identified RVs (at block 460).

[0054] Alternative embodiments may differ from Figure 4A and 4B the method 400 shown therein. For example, the two-step process of method 400-A may result in multiple profiles being determined based on the operating constraints, and then one profile being selected from the multiple profiles based on the road conditions. Additional or alternative factors may be considered to determine one or more profiles. Additionally or alternatively, the profile (area of interest) may be defined based on distance rather than based on the number of RVs of various RV types. Those of ordinary skill in the art will appreciate other such variations.

[0055] Once messages are filtered to exclude messages from RV 130s outside the area of interest, embodiments may additionally employ techniques for prioritizing messages based on the delay budget for each message, which can help smooth the processing demand by delaying message processing where possible, and help ensure that the end-to-end delay budget is met.

[0056] Figure 5 is a simplified block diagram of the relevant communication components of RV 130 and HV 110, which is used to help illustrate the functionality of the different components for message prioritization. It will be understood that the illustrated communication components may be performed by any number of hardware and / or software components of RV 130 and HV 110, such as those illustrated in Figure 10 and described below.

[0057] Here, each vehicle includes an application layer 520 and a radio layer 530. The application layer 520 may include, among other things, an intelligent transportation system (ITS) stack and may be communicatively coupled to the radio layer 530. As previously indicated, the application layer 520-RX of HV 110 may use the techniques described above to determine the area of interest (e.g., define one or more profiles 210). The radio layer 530 may be implemented at the modem of the respective vehicle, may include, among other things, a V2X stack and may be used to convey messages from RV130 to HV 110 (and vice versa).

[0058] As mentioned, traditional V2X messaging can provide an indication of the latency budget used at the radio layer, but may not provide a framework for maintaining an end-to-end latency budget between the application layer 520-TX of the RV 130 and the application layer 520-RX of the HV 110. Embodiments herein may employ functionality at the application layer and / or radio layer to implement such a framework. An example thereof is illustrated in Figure 6 and is described below.

[0059] Figure 6 is a call flow diagram that illustrates the functionality and communication between the various components described in Figure 5 such that the HV 110 can prioritize incoming messages. The functionality of block 610 includes the application layer 520-TX generating a message with a corresponding latency budget. That is, according to an embodiment, when creating a message (e.g., a BSM message), the application layer 520-TX may indicate to the radio layer 530-TX the latency budget for the message, as shown by the arrow 620 in Figure 6 . In some embodiments, the latency budget may be mapped to priorities in a manner similar to how the packet latency budget is mapped to the ProSe per-packet priority (PPPP) for packet data convergence protocol (PDCP) layer communication. That is, certain priorities may be mapped to specific latency budgets. For example, a higher priority level may be mapped to a smaller latency budget (e.g., 20 ms or 50 ms), while a lower priority level may be mapped to a larger latency budget (e.g., 100 ms). As will be appreciated, embodiments may utilize any number of priority levels and / or latency budgets. Additionally, in some embodiments, the latency budget provided by the application layer 520-TX may not be linked to a specific priority level.

[0060] As shown in block 630, the radio layer 530-TX may then determine the remaining latency budget. That is, having the latency budget for the message, the radio layer 530-TX may then calculate how much remaining latency budget will be left for the message once the radio layer 530-TX transmits the message. More specifically, the radio layer 530-TX may determine how much time will remain in the latency budget once the radio layer 530-TX transmits the message based on the known time it spends between receiving the message from the application layer 520-TX and transmitting the message. It may communicate this remaining latency budget with the message, for example, using a reserved field in the physical side link control channel (PSCCH). This communication is shown by the arrow 640 in Figure 6 .

[0061] The functionality of the frame 650 includes the radio layer 530-RX of the HV 110 calculating an updated remaining latency budget by computing the amount of time it takes for the radio layer 530-RX to provide a message to the application layer 520-RX. Additionally, although the over-the-air (OTA) latency may be relatively small, the radio layer 530-RX may also consider the OTA latency when calculating the updated remaining latency budget. The message and an indication of the updated latency budget can then be provided to the application layer 520-RX, as shown by the arrow 670.

[0062] Finally, with the message and the remaining latency budget, the application layer 520-RX can then prioritize message processing, as indicated at block 680. That is, the application layer 520-RX can place the message in a processing queue with other messages based on the amount of remaining latency budget for the message. Thus, processing of messages with little remaining latency budget can be done more quickly, while processing of messages with a large remaining latency budget can be done later. In this way, the application layer 520-RX has some flexibility in the timing of such processing, allowing the application layer 520-RX to smooth spikes in the processing load over time. Given the amount of messages received and their corresponding latency budgets, this can also allow the application layer 520-RX to reduce or increase its operating frequency to accommodate decreases and / or increases in message processing requirements.

[0063] Some embodiments may employ some prioritization in the radio layer 530-RX of the HV 110, as illustrated by block 690. That is, according to some embodiments, the radio layer 530-RX can determine the amount of latency budget remaining for a message and prioritize providing the message to the application layer 520-RX accordingly. For example, it can maintain its own message queue, where the position of each message in the queue is based on the amount of latency budget remaining for each message. In some embodiments, the radio layer 530-RX can perform prioritization of incoming messages in this way as a supplement or replacement to indicating the remaining latency budget to the application layer 520-RX.

[0064] Figure 7 is a flowchart of a method for message selection and prioritization at an HV according to an embodiment. As mentioned, the functionality of the HV can be implemented by hardware and / or software components of a vehicle, such as those illustrated in Figure 10 and described below. Thus, in some embodiments, Figure 7 one or more of the functions illustrated in the blocks of Figure 7 can be performed by one or more of the hardware and / or computer components illustrated in Figure 7The functionality shown in the box. Those of ordinary skill in the art will readily recognize such variations in view of the description herein.

[0065] The functionality of box 710 includes wirelessly receiving messages from multiple RVs. As mentioned with respect to Figure 1 these messages can be received directly from neighboring RVs within the communication range. According to some embodiments, these messages can be received via V2X communication. In embodiments that utilize cellular communication (e.g., C-V2X), such embodiments can use, for example, the PC5 communication interface. As previously discussed, for prioritization purposes, a remaining delay budget can accompany each message (included in the message and / or communicated with the message). According to some embodiments, these messages can include V2X BSMs.

[0066] The apparatus for performing the functionality of box 710 can include one or more software and / or hardware components of a vehicle, such as bus 1001, processor(s) 1010, memory 1060, wireless transceiver 1030, and / or other software and / or hardware components of vehicle 10000 as illustrated in Figure 10 and described in more detail below.

[0067] The functionality shown by box 720 includes determining a first subset of multiple RVs to process messages from the first subset, where the first subset is determined at least in part based on the respective positions of the HRVs relative to the HV, one or more road conditions of the road on which the HV is located, and one or more operating constraints of the HV. As detailed in the embodiments described above with respect to Figure 2A-4B for example, the first subset can be determined using one or more contours to define one or more regions of interest in which the subset of multiple RVs is located. Thus, according to some embodiments, determining a first subset of multiple RVs includes defining multiple subsets of the multiple RVs, where each subset of the multiple subsets includes a different number of RVs from the multiple RVs, and selecting the first subset from the multiple subsets based on one or more operating constraints. As mentioned, each subset can be defined by contours of different orders that define different regions of interest, and the contour can be selected based on its order and the operating condition of the HV. Additionally, according to some embodiments, defining each subset of the multiple subsets can be at least in part based on one or more road conditions.

[0068] As mentioned in the previously described embodiments, one or more road conditions and one or more operational constraints may include any of a variety of relevant factors. For example, according to some embodiments, one or more road conditions may include the number of lanes of a road, the current lane of the HV, the speed limit of the road, road hazards, weather conditions, the curvature of the road, the speed of the HV, the heading of the HV, or the trajectory of one or more of the plurality of RVs, or any combination thereof. According to some embodiments, one or more operational constraints of the HV may include message handling capabilities, thermal constraints, concurrency constraints, or any combination thereof.

[0069] The apparatus for performing the functionality of block 720 may include one or more software and / or hardware components of a vehicle, such as bus 1001, processor(s) 1010, memory 1060, radio transceiver(s) 1030, and / or other software and / or hardware components of vehicle 10000 as illustrated in Figure 10 the description.

[0070] In block 730, the functionality includes, for each message received from an RV in a first subset, determining a priority for the corresponding message based at least in part on an indication of the remaining delay budget for the corresponding message, where the priority for the corresponding message determines the order in which the content of the corresponding message will be processed by the HV, and the indication of the remaining delay budget for the corresponding message is received with the corresponding message. As mentioned in the previously described embodiments, the corresponding message may include or be accompanied by a remaining delay budget determined by the radio layer of the RV transmitting the corresponding message, which may be used by the radio layer and / or application layer of the HV to help ensure that the end-to-end delay budget is met. In some embodiments, for example, determining a priority for the corresponding message includes: obtaining, at the radio layer of the HV, an indication of the remaining delay budget for the corresponding message for the corresponding message; and providing the indication of the remaining delay from the radio layer to the application layer of the HV. In some embodiments, providing the indication of the remaining delay may include providing a modified indication of the remaining delay to account for (i) the delay of the radio layer and (ii) the OTA delay. Additionally or alternatively, the radio layer of the HV may obtain an indication of the remaining delay budget for the corresponding message via the PSCCH for the corresponding message.

[0071] The apparatus for performing the functionality of block 730 may include one or more software and / or hardware components of a vehicle, such as bus 1001, processor(s) 1010, memory 1060, radio transceiver(s) 1030, and / or other software and / or hardware components of vehicle 10000 as illustrated in Figure 10Other software and / or hardware components of the vehicle 1000 as described herein. According to some embodiments, for example, the radio layer may be performed by the wireless transceiver(s) 1030 and the application layer may be performed by the processor(s) 1010 and / or the DSP 1020.

[0072] As mentioned in the above embodiments, the functionality performed at block 720 may include filtering messages from RVs in a plurality of RVs that are not in the first subset. This filtering may be performed at the radio layer (e.g., the modem), the application layer, or a combination of both. Additionally or alternatively, message ordering (e.g., the functionality of block 730) for messages from RVs in the first subset may be performed at the radio layer (e.g., Figure 6 optional prioritization at block 690 of the radio layer 530-Rx in Figure 6 or at the application layer (e.g.,

[0073] Figure 8-10 is an illustration of systems, structural devices, vehicle components, and other devices, components, and systems that may be used to implement the techniques for message filtering and prioritization in the HV 110 provided herein. In the following description, the HV 110 and RV 130 used in the previously described embodiments are generally referred to simply as "vehicles".

[0074] Figure 8Explanation of a system according to an embodiment in which a vehicle (e.g., HV and / or RV) can communicate on various networks and with various devices, vehicles, and servers. In one embodiment, V2X vehicle A 880 can communicate with V2X or otherwise enabled communication transceiver vehicle B 890 on link 823 using V2X or other wireless communication transceiver, e.g., in one embodiment, to perform relative positioning between vehicles, negotiation for lane change or for crossing an intersection, and exchange of V2X data elements (such as global navigation satellite system (GNSS) measurements, vehicle status, vehicle location and vehicle capabilities, measurement data, and / or calculated status), and exchange of other V2X vehicle status steps that may not be covered in V2X capability data elements. In one embodiment, vehicle A 880 can also communicate with vehicle B 890 over a network, e.g., via wireless signal 822 to / from base station 820 and / or via wireless signal 832 to / from access point 830, or via one or more communication-enabled RSU 825, any of which can relay communication, information, and / or translate protocols for use by other vehicles (such as vehicle B 890), specifically in one embodiment, where vehicle B 890 cannot directly communicate with vehicle A 880 according to a common protocol. In one embodiment, the (a) RSU can include various types of roadside beacons, traffic and / or vehicle monitors, traffic control devices, and location beacons.

[0075] In one embodiment, the RSU(s) 825 may have a processor 825A configured to operate a wireless transceiver 825E to send and receive wireless messages (e.g., BSM or Cooperative Awareness Messages (CAM) or other V2X messages) to / from vehicle A 880 and / or vehicle B 890, from base station 820 and / or access point 830. For example, the wireless transceiver 825E may send and / or receive wireless messages according to various protocols (such as V2X communication with vehicles), and / or communicate on a wireless communication network using various wide area network (WAN), wireless local area network (WLAN), and / or personal area network (PAN) protocols. In one embodiment, the RSU(s) 825 may include one or more processors 825A communicatively coupled to the wireless transceiver 825E and a memory, and may include instructions and / or hardware to act as a traffic control unit 825C, and / or provide and / or process environmental and roadside sensor information 825D or serve as a position reference for the GNSS relative position between it and the vehicle. In one embodiment, the RSU(s) 825 may include a network interface 825B (and / or the wireless transceiver 825E), and in an embodiment, the network interface 825B may communicate with external servers (such as a traffic optimization server 865, a vehicle information server 855, and / or an environmental data server 840). In one embodiment, the wireless transceiver 825E may communicate on a wireless communication network by transmitting or receiving wireless signals from a wireless base transceiver subsystem (BTS), Node B, or evolved Node B (eNodeB) or next generation Node B (gNodeB) over a wireless communication link. In one embodiment, the wireless transceiver(s) 825E may include various combinations of WAN, WLAN, and / or PAN transceivers. In one embodiment, the local transceiver may also be a transceiver, a ZigBee transceiver, or other PAN transceiver. The local transceiver, WAN wireless transceiver, and / or mobile wireless transceiver may include a WAN transceiver, an access point (AP), a femtocell, a home base station, a small cell base station, a home Node B (HNB), a home evolved Node B (HeNB), or a next generation Node B (gNodeB) and may provide access to a wireless local area network (WLAN, e.g., an IEEE 802.11 network), a wireless personal area network (PAN, e.g., a Bluetooth network), or a cellular network (e.g., an LTE network or other wireless wide area network, such as those discussed in the next paragraph). It should be understood that these are merely examples of networks that may communicate with the RSU(s) 825 over a wireless link, and the claimed subject matter is not limited in this regard.

[0076] (The) RSU 825 can receive location, status, GNSS and other sensor measurements, and capability information from vehicle A 880 and / or vehicle B 890, such as GNSS measurements, sensor measurements, speed, heading, location, stopping distance, priority or emergency status, and other vehicle-related information. In one embodiment, environmental information (such as road surface information / status, weather status, and camera information) can be collected via point-to-point or broadcast messaging and shared with vehicles. (The) RSU 825 can utilize the information received from vehicle A 880 and / or vehicle B 890, the environment, and roadside sensors 825D via wireless transceiver 825E, and network information and control messages from, for example, traffic control and optimization server 865 to coordinate and direct traffic flow and provide environmental, vehicle, safety, and notification messages to vehicle A 880 and vehicle B 890.

[0077] Processor 825A can be configured to operate network interface 825B. In one embodiment, network interface 825B can be connected to network 870 via a backhaul. And in an embodiment, network interface 825B can be used to communicate and coordinate with various centralized servers (such as centralized traffic control and optimization server 865), which monitor and optimize traffic flow in an area (such as within a city or a city section or a region). Network interface 825B can also be used for remote access to (the) RSU 825 for crowdsourcing vehicle data, maintenance of (the) RSU 825, and / or coordination with other (the) RSU 825 or other purposes. (The) RSU 825 can have a processor 825A configured to operate traffic control unit 825C, which can be configured to process data received from vehicles (such as vehicle A 880 and vehicle B 890), such as location data, stopping distance data, road condition data, identification data, and other information related to the status and location of nearby vehicles and the environment. (The) RSU 825 can have a processor 825A configured to obtain data from environmental and roadside sensors 825D, which can include temperature, weather, cameras, pressure sensors, road sensors (e.g., for vehicle detection), accident detection, motion detection, speed detection, and other vehicle and environmental monitoring sensors.

[0078] In one embodiment, vehicle A 880 may also use short-range communication and personal networks (such as Bluetooth, Wi-Fi, or Zigbee or via V2X or other vehicle-related communication protocols) to communicate with mobile device 800. For example, in one embodiment, to access a WAN and / or Wi-Fi network and / or in one embodiment to obtain sensor measurements and / or location measurements from mobile device 800. In one embodiment, vehicle A 880 may communicate with mobile device 800 using WAN-related protocols over a WAN network, such as via WAN base station 820 or communicate directly peer-to-peer using Wi-Fi or via a Wi-Fi access point. Vehicle A 880 and / or vehicle B 890 may communicate using various communication protocols. In one embodiment, vehicle A 880 and / or vehicle B 890 may support various and multiple wireless communication modes (such as, for example, using V2X, Global System for Mobile Communications (GSM), Wideband Code Division Multiple Access (WCDMA), Code Division Multiple Access (CDMA), High Rate Packet Data (HRPD), Wi-Fi, Bluetooth, WiMAX, LTE, 5G New Radio Access Technology (NR) communication protocols, etc.).

[0079] In one embodiment, vehicle A may communicate over a WAN network using a WAN protocol via base station 820 or communicate with a wireless LAN access point 830 using a wireless LAN protocol (such as Wi-Fi). The vehicle may also support wireless communication using, for example, WLAN, PAN (such as Bluetooth or ZigBee), Digital Subscriber Line (DSL), or packet cable.

[0080] In one embodiment, vehicle A 880 and / or vehicle B 890 may include one or more GNSS receivers (such as GNSS receiver 1070) for receiving GNSS signals 812 from GNSS satellites 810 for position determination, time capture, and time maintenance. Various GNSS systems may be supported individually or in combination, such that GNSS receiver 1070 or other receivers are used to receive signals from Beidou, Galileo, GLONASS, and / or Global Positioning System (GPS) and various regional navigation systems (such as Quasi-Zenith Satellite System (QZSS) and NavIC or Indian Regional Navigation Satellite System (IRNSS)). Other wireless systems may be utilized, such as those depending on beacons (such as, in one example, one or more RSU 825, one or more wireless LAN access points 830, or one or more base stations 820). Various GNSS signals 812 may be used in conjunction with automotive sensors to determine position, speed, and proximity to other vehicles (such as between vehicle A 880 and vehicle B 890).

[0081] In one embodiment, vehicle A and / or vehicle B may access GNSS measurements and / or positions determined at least in part using GNSS provided by mobile device 800. In one embodiment, mobile device 800 also has GNSS, WAN, Wi-Fi, and other communication receivers and / or transceivers. In one embodiment, vehicle A 880 and / or vehicle B 890 may access GNSS measurements (such as pseudorange measurements, Doppler measurements, and satellite IDs) and / or positions determined at least in part using GNSS provided by mobile device 800 as a fallback in situations where the GNSS receiver 1070 fails or provides position accuracy below a threshold level.

[0082] Vehicle A 880 and / or vehicle B 890 may access various servers on the network (such as vehicle information server 855, route server 845, location server 860, map server 850, and environmental data server 840).

[0083] Vehicle information server 855 may provide information describing various vehicles (such as antenna position, vehicle size, and vehicle capabilities), which can be used to make decisions regarding maneuvers relative to nearby vehicles (such as whether they can stop or accelerate in time, whether they are self-driving, whether they have self-driving capabilities, whether they have communication capabilities). In one embodiment, vehicle information server 855 may also provide information regarding vehicle size, shape, capabilities, identification, ownership, occupancy, and / or determined position points (such as, for example, the position of the GNSS receiver) and the position of the vehicle boundary relative to the determined position points.

[0084] Route server 845 may receive current position and destination information and provide route planning information, map data, alternative route data, and / or traffic and street condition data for the vehicle.

[0085] In one embodiment, the location server 860 may provide location determination capabilities, transmitter signal acquisition assistance (such as GNSS satellite orbit prediction information, time information approximate location information, and / or approximate time information), transceiver almanacs (such as those containing the identification and location of Wi-Fi access points and base stations), and in some embodiments, additional route-related information (such as speed limits, traffic, and road / structure conditions). The map server 850 may provide map data such as road locations, points of interest along roads, address locations along roads, road sizes, road speed limits, traffic conditions, and / or road conditions (wet, slippery, snow / ice, etc.), road status (open, under construction, accident, etc.). In one embodiment, the environmental data server 840 may provide weather and / or road-related information, traffic information, terrain information, and / or road quality and speed information, and / or other relevant environmental data.

[0086] In one embodiment, Figure 8 Vehicles 880 and 890 and mobile device 800 in [description] may communicate over network 870 via various network access points (such as wireless LAN access point 830 or wireless WAN base station 820 on network 870). In some embodiments, vehicles 880 and 890 and mobile device 800 may also use various short-range communication mechanisms to communicate directly between devices, between vehicles, and between device-to-vehicle and vehicle-to-device without going through network 870 (such as via Bluetooth, Zigbee, and 5G New Radio standards).

[0087] Figure 9 A functional block diagram of a vehicle 1000 according to one embodiment is shown. Vehicle 1000 may correspond to HV110 and / or RV 130 as described in the above embodiments. Additionally, the hardware and / or software components for performing the blocks shown in [description] are illustrated in [description] and described in more detail below. Figure 9 shown in [description] Figure 10 are illustrated in [description] and described in more detail below.

[0088] As Figure 9As shown, vehicle 1000 may receive vehicle and environmental information from vehicle external sensors 902, vehicle internal sensors 904, vehicle capabilities 906, external wireless information (such as the location of the RV and GNSS measurement information) 908 (from the environment, from other vehicles, from (a) RSU, from the system server) and / or from the vehicle motion state 910 (describing the current and / or future motion state). Messages received by the HV 110 from the RV 130 described in the above embodiments may convey, for example, the data provided in blocks 908 and / or 910. In one embodiment, the received vehicle, sensor, and environmental information may be processed in one or more processors 1010, DSP 1020, and memory 1060 ( Figure 10 as shown), the processors 1010, DSP 1020, and memory 1060 are connected and configured to provide external object sensing and classification, prediction and planning, and maneuver execution, and to determine and update V2X or other wireless data element values (including GNSS data element values) and to transmit message exchanges including the determined data elements via one or more wireless transceivers 1030. Message exchanges and data elements may be sent and received via various devices, protocols, and standards, such as via SAE or European Telecommunications Standards Institute (ETSI) CV2X messages and data elements or other wireless and wireless V2X protocols supported by (a) wireless transceiver 130.

[0089] The inter-vehicle relative position determination block 928 may be used to determine the relative position of vehicles in the area of interest. In one embodiment, GNSS data is exchanged with a vehicle (e.g., RV) or other device (such as an RSU) to determine and / or verify and / or improve the accuracy of the relative position associated with other vehicles or devices. In one embodiment, vehicles (or other devices) within the area of interest may utilize broadcast position information (such as the broadcast latitude and longitude received in messages from other vehicles, other devices (e.g., BSM)) and the position information of vehicle 1000 to determine an approximate relative position and / or an approximate distance between vehicles. This information may be used by the HV 110, for example, to define the profile 210 as described in the above embodiments and / or to identify the RV 130 within the area of interest.

[0090] In one embodiment, other vehicle-related input sources (such as servers 855, 845, 860, 850, and 840) can provide information (such as vehicle information, route planning, position assistance, map data, and environmental data) and provide inputs and / or supplement and / or combine with other inputs (such as road position data, map data, driving condition data, and other vehicle-related data inputs) that are used in combination with vehicle-to-vehicle maneuver coordination 924 to determine maneuver execution 926. In one embodiment, map data can include the position of roadside units relative to road positions, where a vehicle can use relative positioning between RSUs in combination with map data to determine its position relative to the road surface, especially in cases where other systems may fail (such as due to low visibility weather conditions (snow, rain, sandstorms, etc.)). In one embodiment, map data from map server 850 can be combined with relative and / or absolute data from adjacent vehicles and / or from (such) RSUs 825 to determine the highly confident absolute positions of multiple vehicles and their relative positions with respect to the road / map. For example, if vehicle A 880 has a higher accuracy / higher confidence position than other vehicles in communication with vehicle A 880, such as vehicle B 890, vehicle B 890 can use GNSS information to obtain a highly accurate relative position and use the highly accurate position sent from vehicle A 880 to vehicle B 890 to determine the highly accurate position of vehicle B 890, even if vehicle B 890's system is otherwise unable to calculate a highly accurate position in a particular scenario or environment. In this case, the presence of vehicle A with a highly accurate position determination system benefits all surrounding vehicles by sharing one or more highly accurate positions along with ongoing relative position information. Additionally, assuming the map data from map server 850 is accurate, the ability to propagate highly accurate position data from vehicle A 880 to surrounding vehicles (such as vehicle B 890) enables the surrounding vehicles to also accurately determine their relative positions with respect to the map data, even in other difficult signal / position environments. The vehicle information server 855 can provide vehicle information (such as size, shape, and antenna position), which can be used by, for example, vehicle A or other vehicles to determine not only the relative position between the GNSS receiver on vehicle A 880 and, for example, vehicle B 890, but also the distance between the closest points of vehicle A 880 and vehicle B 890. In one embodiment, traffic information from the traffic control and optimization server 865 can be used to determine overall path selection and route replanning, which is used in combination with the route server 845 (in one embodiment).In one embodiment, the environmental data server 840 may provide inputs regarding road conditions, black ice on the road, snow, water on the road, and other environmental conditions, which may also affect the decisions and decision criteria in the inter-vehicle maneuver coordination block 924 and the maneuver execution block 926. For example, in icy or rainy conditions, the vehicle 1000 may execute and / or request an increased inter-vehicle distance from adjacent vehicles or may select a route option that avoids road hazard conditions (such as black ice and standing water).

[0091] Block 928 may be implemented using a variety of dedicated or general-purpose hardware and software (such as using the processor 1010 and / or the DSP 1020 and the memory 1060) (again, as shown in Figure 10 ), or in one embodiment, implemented in a dedicated hardware block (such as a dedicated sensor processing and / or vehicle messaging core). According to some embodiments, the positions of nearby vehicles may be determined by various means, such as based on signal timing measurements (such as round-trip time (RTT) and time of arrival (TOA)), the signal strength of broadcast signals for the vehicle, and the distance determined based on the broadcast latitude and longitude from adjacent vehicles and the current position of the vehicle. Additionally or alternatively, the positions of nearby vehicles may be determined from sensor measurements (such as light detection and ranging (LIDAR), radio detection and ranging (radar), sonar, and camera measurements). In one embodiment, some or all of the blocks 902, 904, 906, 908, and / or 910 may have dedicated processing cores, for example, to improve performance and reduce measurement latency. In one embodiment, some or all of the blocks 902, 904, 906, 908, and / or 910 may share processing with block 928.

[0092] In some embodiments, the vehicle exterior sensing 902 may include cameras, LIDAR (Light Detection and Ranging), radar, proximity sensors, rain sensors, weather sensors, GNSS receivers 1070, and data received using these sensors (such as map data, environmental data, location, route) and / or other vehicle information (such as may be received from other vehicles, devices, and servers (such as, in one embodiment, map server 850, route server 845, vehicle information server 855, environmental data server 840, location server 860) and / or from associated devices (such as mobile device 800), which may be present in or near the vehicle (such as vehicle A 880)). For example, in one embodiment, the mobile device 800 may provide an additional source of GNSS measurements, may provide an additional source of motion sensor measurements, or may provide network access as a communication portal to a WAN, Wi-Fi, or other network, and as a gateway to various information servers (such as servers 840, 845, 850, 855, 860, and / or 865).

[0093] It should be understood that the vehicle 1000 may include one or more cameras. In one embodiment, the cameras may be front-mounted, side-mounted, rear-mounted, or have an adjustable field of view (such as a rotatable camera). As Figure 11 shown, for example, there may be multiple cameras 1106 facing the same plane. For example, the camera 1106 and the camera mounted at 1108 on the bumper may include two front cameras, one focused on lower objects and / or having a lower field of view for parking purposes (such as mounted on the bumper), and one focused on a higher field of view (such as tracking traffic, other vehicles, pedestrians, and more distant objects). In one embodiment, the various views may be stitched together and / or may be associated with other inputs (such as V2X inputs from other vehicles) to optimize the tracking of other vehicles and external entities and objects and / or to calibrate the sensor systems against each other. The LIDAR 1104 may be mounted on top and rotated or may be focused on a specific field of view (such as forward, backward, or sideward). The LIDAR 1104 may be solid-state or mechanical. The proximity sensors may be ultrasonic, radar-based, light-based (such as infrared ranging-based), and / or capacitive (capacitive detection for surface touch or metal bodies). The rain and weather sensors may include various sensing capabilities and technologies, such as barometric pressure sensors, humidity detectors, rain sensors, and / or light sensors, and / or may utilize other pre-existing sensor systems. The GNSS receiver may be mounted on top, such as in a fin-type antenna assembly at the rear of the vehicle roof, mounted on the hood or dashboard, or otherwise placed outside or inside the vehicle.

[0094] In one embodiment, the vehicle interior sensors 904 may include wheel sensors 1112 (such as tire pressure sensors, brake pad sensors, brake status sensors, speedometers, and other speed sensors), heading sensors and / or orientation sensors (such as magnetometers and geomagnetic compasses), distance sensors (such as odometers and wheel tick sensors), inertial sensors (such as accelerometers and gyroscopes), and inertial positioning results using the sensors mentioned above, as well as yaw, pitch, and / or roll sensors that may be determined individually or using other sensor systems (such as accelerometers, gyroscopes, and / or tilt sensors).

[0095] Both the vehicle interior sensors 904 and the vehicle exterior sensors 902 may have shared or dedicated processing capabilities. For example, a sensor system or subsystem may have one or more sensor processing cores that determine vehicle state values (such as yaw, pitch, roll, heading, speed, acceleration capabilities, and / or distance, and / or stopping distance) based on measurements and other inputs from accelerometers, gyroscopes, magnetometers, and / or other sensing systems. Different sensing systems may communicate with each other to determine measurement values or send values to block 928 to determine the vehicle position. The vehicle state values derived from the measurements of the interior and exterior sensors may be further combined with vehicle state values and / or measurements from other sensor systems using a general or application processor. For example, block 928 and / or 924 may be implemented on a dedicated or centralized processor to determine data element values for V2X messaging, which may be transmitted using the wireless transceiver 1030 or via other communication transceivers. In one embodiment, the sensors may be divided into related systems, for example, LIDAR, radar, motion, wheel systems, etc., which operate through dedicated core processing of the raw results to output vehicle state values from each core, and these vehicle state values are combined and interpreted to derive combined vehicle state values, including capability data elements and status data elements, and these combined vehicle state values may be used to control or otherwise affect vehicle operation and / or be shared with other vehicles and / or systems as a messaging step via V2X or other messaging capabilities. In one embodiment, these messaging capabilities may be based on various wireless-related, optical-related, or other communication standards, such as those supported by the wireless transceiver(s) 1030 and the antenna(s) 1032.

[0096] In one embodiment, vehicle capabilities 906 may include performance estimates for stopping, braking, accelerating, and turning radius, as well as autonomous and / or non-autonomous states and / or capabilities or the performance of such capabilities. The capability estimates may be based on stored estimates which, in one embodiment, may be loaded into a memory. These estimates may be based on empirical performance numbers, either specific to a particular vehicle or averaged across one or more vehicles, and / or one or more models for a given performance metric. Where performance estimates from multiple models are averaged or otherwise combined, they may be selected based on similar or common characteristics. For example, vehicles having similar or identical weights and the same or similar drivetrains may share performance estimates for estimates related to driving performance (such as braking / stopping distance, turning radius, and acceleration performance). Vehicle performance estimates may also be obtained, for example, using (an) external V2X input 908 over a wireless network from a vehicle data server on the network. This is particularly helpful for obtaining information on vehicles that do not have wireless capabilities and cannot directly provide vehicle information. In one embodiment, vehicle capabilities 906 may also be affected by the state of automotive components such as tire wear, tire brand capabilities, brake pad wear, brake brand and capabilities, and engine state. In one embodiment, vehicle capabilities 906 may also be affected by the overall vehicle state (such as speed, heading) and external factors (such as road surface, road conditions (wet, dry, slippery / traction), weather (windy, rainy, snowy, black ice, slick roads, etc.). In many cases, wear or other system degradation, as well as external factors (such as weather, road surface, road conditions, etc.) may be used to reduce, validate, or improve performance estimates. In some embodiments, the actual measured vehicle performance (such as measuring vehicle stopping distance and / or acceleration time per distance) may be measured and / or estimated based on actual vehicle driving-related performance. In one embodiment, if the measurements are inconsistent, the most recently measured performance may be weighted more heavily or given preference over older measurements. Similarly, in one embodiment, measurements obtained during similar conditions (such as on the same type of weather or the same type of road surface as currently detected by the vehicle (such as via vehicle external sensors 902 and / or vehicle internal sensors 904)) may be weighted more heavily and / or given preference when determining capabilities.

[0097] V2X vehicle sensing, prediction, planning, and execution 912 processes the reception and handling of information from frames 902, 904, 906, 908, and 910 via external object sensing and classification box 914, and partially utilizes sensor fusion and object classification box 916 to correlate, verify, and / or combine data from input frames 902, 904, 906, 908, and 910. External object sensing and classification in box 914 determines the objects present, determines the type of the objects (such as cars, trucks, bicycles, motorcycles, pedestrians, animals, etc.) and / or the object state relative to the vehicle (such as moving state, proximity, heading, and / or position relative to the vehicle, size, threat level, and vulnerability priority (e.g., pedestrians will have a higher vulnerability priority than road debris)). In one embodiment, box 914 can utilize GNSS measurement messages from other vehicles to determine the relative positioning to other vehicles. This output from box 914 can be provided to prediction and planning box 918, which determines the detected objects and the vehicle and their associated trajectories via box 920, and determines vehicle maneuvers and path planning in box 922, whose output is directly utilized in box 926 vehicle maneuver execution or utilized via V2X inter-vehicle negotiation box 924. V2X inter-vehicle negotiation box 924 will integrate and account for the maneuver plans, positions, and states received from other vehicles. V2X inter-vehicle negotiation accounts for the states of neighboring vehicles and realizes negotiation and coordination between neighboring or otherwise affected vehicles based on vehicle priorities, vehicle capabilities (such as the ability to stop, decelerate, or accelerate to avoid collisions), and in some embodiments, various conditions (such as weather conditions (rain, fog, snow, wind), road conditions (dry, wet, ice, slippery)). These include, for example, negotiation of the timing and sequence for passing through an intersection between cars approaching the intersection, negotiation of lane changes between adjacent cars, negotiation for parking spaces, negotiation for entry into one-way roads for directional travel or overtaking another vehicle. Inter-vehicle negotiation can also include time-based and / or distance-based factors, such as agreed-upon times, destination distances, and estimated route times to reach the destination, and in some embodiments, the type of agreement and the importance of the agreement.

[0098] Figure 10FIG. 0 is a block diagram of various hardware and software components of a vehicle 1000 according to one embodiment. Again, vehicle 1000 may correspond to HV 110 and / or RV 130 described in the above embodiments. Further, the vehicle may include, for example, an automobile, a truck, a motorcycle, and / or other motor vehicles, and may transmit and receive radio signals to / from other vehicles 1000 and / or transmit and receive radio signals to / from a wireless communication network 870 (in one embodiment, via a WAN, a base station 820, and / or a wireless access point 830), and / or transmit and receive radio signals to / from one or more RSUs 825, and / or transmit and receive radio signals to / from other vehicles 1000 (e.g., vehicle 880) may communicate with other vehicles (e.g., vehicle 890) and / or a wireless communication network via one or more wireless transceivers 1030 and one or more wireless antennas 1032 by transmitting wireless signals to a remote wireless transceiver or receiving wireless signals from a remote wireless transceiver over a wireless communication link, the remote wireless transceiver may include another vehicle 890, a base station 820 (e.g., a B node, an eNodeB, or a gNodeB), or a wireless access point 830.

[0099] Similarly, vehicle 1000 can transmit wireless signals to or receive wireless signals from a local transceiver over a wireless communication link, e.g., by using a WLAN and / or PAN wireless transceiver, represented herein by one of (the) wireless transceivers 1030 and (the) wireless antennas 1032. In one embodiment, (the) wireless transceivers 1030 can include various combinations of WAN, WLAN, and / or PAN transceivers. In one embodiment, (the) wireless transceivers 1030 can further include a Bluetooth transceiver, a ZigBee transceiver, or other PAN transceivers. In one embodiment, vehicle 1000 can transmit wireless signals to or receive wireless signals from the wireless transceiver 1030 on vehicle 1000 over wireless communication link 1034. The local transceiver, WAN wireless transceiver, and / or mobile wireless transceiver can include a WAN transceiver, an access point (AP), a femtocell, a home base station, a small cell base station, an HNB, a HeNB, or a gNodeB and can provide access to a wireless local area network (WLAN, e.g., an IEEE 802.11 network), a wireless personal area network (PAN, e.g., a Bluetooth network), or a cellular network (e.g., an LTE network or other wireless wide area network, such as those discussed in the next paragraph). Of course, it should be understood that these are merely examples of networks that can communicate with the vehicle over a wireless link, and the claimed subject matter is not limited in this respect. It should also be understood that (the) wireless transceivers 1030 can be located on various types of vehicles 1000 (such as boats, ferries, cars, buses, drones, and various transportation vehicles). In one embodiment, vehicle 1000 can be used for passenger transportation, package transportation, or other purposes. In one embodiment, GNSS signals 1074 from GNSS satellites are used by vehicle 1000 for position determination and / or for determination of GNSS signal parameters and demodulated data. In one embodiment, signals 1034 from (the) WAN transceiver, WLAN, and / or PAN local transceiver are used for position determination either alone or in combination with GNSS signals 1074.

[0100] Examples of network technologies that can support wireless transceiver 1030 are GSM, CDMA, WCDMA, LTE, 5G, or new radio access technology (NR), HRPD, and V2X vehicle-to-vehicle communication. As mentioned, the V2X communication protocol can be defined in various standards (such as SAE and ETS-ITS standards). GSM, WCDMA, and LTE are technologies defined by 3GPP. CDMA and HRPD are technologies defined by the Third Generation Partnership Project II (3GPP2). WCDMA is also part of the Universal Mobile Telecommunications System (UMTS) and can be supported by an HNB.

[0101] The wireless transceiver 1030 can communicate with a communication network via WAN wireless base stations, which can include the deployment of equipment that provides subscribers with access to a wireless telecommunications network for services (e.g., under a service contract). Here, the WAN wireless base stations can perform the functions of WAN or cell base stations to serve subscriber devices within a cell determined at least in part based on the range within which the WAN wireless base stations can provide access services. Examples of WAN base stations include GSM, WCDMA, LTE, CDMA, HRPD, Wi-Fi, Bluetooth, WiMAX, 5G NR base stations. In one embodiment, further wireless base stations can include WLAN and / or PAN transceivers.

[0102] In one embodiment, the vehicle 1000 can include one or more cameras 1035. In one embodiment, the cameras can include camera sensors and mounting assemblies. Different mounting assemblies can be used for different cameras on the vehicle 1000. For example, a front camera can be mounted in the front bumper, in the stem of the rearview mirror assembly, or in other front areas of the vehicle 1000. A rear camera can be mounted in the rear bumper / fender, on the rear windshield, in the trunk, or on other rear areas of the vehicle. Side mirrors can be mounted on the sides of the vehicle, such as integrated into the mirror assembly or the door assembly. The cameras can provide object detection and distance estimation (especially for objects of known size and / or shape (e.g., both stop signs and license plates have standardized sizes and shapes)), and can also provide information about rotational movement relative to the axis of the vehicle (such as during a turn). When used in conjunction with other sensors, the cameras can be calibrated to verify travel distance and angular orientation by using other systems (such as by using LIDAR, wheel tick / distance sensors, and / or GNSS). The cameras can similarly be used to verify and calibrate other systems to verify that distance measurements are correct (e.g., by calibrating against known distances between known objects (landmarks, roadside markers, road mile markers, etc.)), and are also used to verify that object detection is performed accurately so that objects are mapped to the correct position relative to the vehicle by LIDAR and other systems. Similarly, when combined with, for example, an accelerometer, the time of impact with a road hazard obstacle can be estimated (e.g., the time elapsed before hitting a pothole), which can be verified against the actual impact time and / or against a stopping model (e.g., compared with the estimated stopping distance in the case of attempting to stop before hitting an object) and / or against a maneuvering model (verifying whether the current estimate of the turning radius at the current speed and / or the current measurement of maneuverability at the current speed are accurate under the current conditions and modifying the estimated parameters accordingly based on camera and other sensor measurements).

[0103] In one embodiment, an accelerometer, a gyroscope, and a magnetometer 1040 can be used to provide and / or verify motion and orientation information. The accelerometer and the gyroscope can be used to monitor wheel and driveline performance. In one embodiment, the accelerometer can also be used to verify the actual collision time of a road hazard obstacle (such as a pothole) relative to a predicted time based on existing stop and acceleration models and a steering model. In one embodiment, the gyroscope and the magnetometer can be used to measure the rotational state of the vehicle and the orientation relative to magnetic north, respectively, and are used to measure and calibrate an estimate and / or model of the turning radius at a current speed and / or a maneuverability measurement at a current speed (especially when used in conjunction with measurements from other external and internal sensors (such as other sensors 1045, such as a speed sensor, a wheel tick sensor, and / or an odometer measurement)).

[0104] LIDAR 1050 uses pulsed lasers to measure the distance to an object. While cameras can be used for object detection, LIDAR 1050 provides a means for more deterministically detecting the distance (and orientation) of an object (especially with respect to an object of unknown size and shape). LIDAR 1050 measurements can also be used to estimate the travel rate, vector direction, relative position, and stopping distance by providing accurate distance measurements and incremental distance measurements.

[0105] Memory 1060 can be used in conjunction with processor 1010 and / or DSP 1020 and can include random access memory (RAM), read-only memory (ROM), disk drives, FLASH, or other memory devices or various combinations thereof. In one embodiment, memory 1060 can contain instructions for implementing the various methods described throughout this specification, including, for example, processes for implementing the use of relative positioning between vehicles and between a vehicle and an external reference object (such as a roadside unit). In one embodiment, the memory can contain instructions for operating and calibrating sensors and for receiving maps, weather, vehicle (both vehicle 1000 and surrounding vehicles, such as HV 110 and RV 130), and other data, and for determining driving parameters (such as relative position, absolute position, stopping distance, acceleration, and turning radius at a current speed and / or maneuverability at a current speed, inter-vehicle distance, turn initiation / timing and performance, and initiation / timing of driving operations) using various internal and external sensor measurements and the received data and measurements.

[0106] In one embodiment, the power and drive systems (generator, battery, transmission, engine) and associated systems 1075 and systems 1055 (brakes, actuators, throttle control, steering, and electrical) may be controlled by one or more processors and / or hardware or software or by the operator of the vehicle or by some combination thereof. Systems 1055 (such as brakes, actuators, throttle control, steering, and electrical) and power and drive or other systems 1075 may be used in combination with performance and operating parameters to achieve safe and accurate driving and operation of vehicle 1000 autonomously (and manually, with respect to alerts and emergency override / braking / stopping), such as to safely, effectively, and efficiently merge into traffic, stop, accelerate, and otherwise operate vehicle 1000. In one embodiment, inputs from various sensor systems (such as camera 1035, accelerometers, gyroscopes, and magnetometers 1040, LIDAR 1050, GNSS receiver 1070, radar 1053, inputs from one or more wireless transceivers 1030 and / or other sensors 1045 or various combinations thereof, messaging, and / or measurements) may be used by processor 1010 and / or DSP 1020 or other processing systems to control power and drive system 1075 and systems 1055 (brakes, actuators, throttle control, steering, and electrical).

[0107] A Global Navigation Satellite System (GNSS) receiver 1070 can be used to determine a position relative to the ground (absolute position), and when used in conjunction with other information (such as measurements from other objects and / or map data), can be used to determine a position relative to other objects (such as relative to other vehicles and / or relative to the road surface). To determine the position, the GNSS receiver 1070 can use one or more antennas 1072 (which may be the same as antenna 1032 depending on the functional requirements) to receive RF signals 1074 from GNSS satellites (e.g., receive RF signal 812 from GNSS satellite 810). The GNSS receiver 1070 can support one or more GNSS constellations and other satellite-based navigation systems. For example, in one embodiment, the GNSS receiver 1070 can support Global Navigation Satellite Systems such as GPS, GLONASS, Galileo, and / or Beidou, or any combination thereof. In one embodiment, the GNSS receiver 1070 can support regional navigation satellite systems (such as NavIC or QZSS or a combination thereof) and various augmentation systems (e.g., satellite-based augmentation system (SBAS) or ground-based augmentation system (GBAS)), such as Doppler Orbitography and Radiopositioning Integrated by Satellite (DORIS) or Wide Area Augmentation System (WAAS) or European Geostationary Navigation Overlay Service (EGNOS) or Multi-functional Satellite Augmentation System (MSAS) or Local Area Augmentation System (LAAS). In one embodiment, the (s)GNSS receivers 1030 and (s)antennas 1032 can support multiple frequency bands and sub-bands, such as GPS L1, L2, and L5 frequency bands, Galileo E1, E5, and E6 frequency bands, Compass (Beidou) B1, B3, and B2 frequency bands, GLONASS G1, G2, and G3 frequency bands, and QZSS L1C, L2C, and L5-Q frequency bands.

[0108] The GNSS receiver 1070 can be used to determine positions and relative positions that can be used for positioning and navigation, and to calibrate other sensors when appropriate, such as for determining the distance between two time points under clear sky conditions and using the distance data to calibrate other sensors (such as an odometer and / or LIDAR). In one embodiment, GNSS-based relative positions based on, for example, Doppler and / or pseudorange measurements shared between vehicles can be used to determine a highly accurate distance between two vehicles, and when combined with vehicle information (such as shape and model information and GNSS antenna position), can be used to calibrate, validate, and / or influence the confidence levels associated with information from LIDAR, cameras, radar, sonar, and other distance estimation techniques. GNSS Doppler measurements can also be used to determine the linear and rotational motion of a vehicle or a vehicle relative to another vehicle, which can be used in combination with gyroscopes and / or magnetometers and other sensor systems to maintain the calibration of those systems based on the measured position data. The relative GNSS position data can also be combined with high-confidence absolute positions from RSU to determine the high-confidence absolute position of the vehicle. Additionally, during adverse weather conditions that may obscure LIDAR and / or camera-based data sources, relative GNSS position data can be used to avoid other vehicles and stay within a lane or other assigned road area. For example, using an RSU equipped with a GNSS receiver and V2X capabilities, GNSS measurement data can be provided to the vehicle, which, when provided together with the absolute position of the RSU, can be used to navigate the vehicle relative to a map, thereby keeping the vehicle in the lane and / or on the road despite a lack of visibility.

[0109] The radar 1053 uses the transmitted radio waves reflected from an object. The reflected radio waves are analyzed based on the time required for the reflection to arrive and other signal characteristics of the reflected wave to determine the position of nearby objects. The radar 1053 can be used to detect the positions of nearby cars, roadside objects (signs, other vehicles, pedestrians, etc.), and can generally detect objects even in adverse weather (such as snow, rain, or hail). Thus, the radar 1053 can be used to supplement the LIDAR 1050 system and the camera 1035 system to provide ranging information to other objects by providing ranging and distance measurement and information when vision-based systems typically fail. Additionally, the radar 1053 can be used to calibrate and / or perform a sanity check on other systems (such as LIDAR 1050 and camera 1035). The ranging measurements from the radar 1053 can be used to determine / measure the stopping distance, acceleration, maneuverability at the current speed, and / or the turning radius at the current speed and / or the maneuverability measurement at the current speed. In some systems, ground-penetrating radar can also be used to track the road surface via, for example, radar reflection markers on the road surface or terrain features such as ditches.

[0110] Figure 11 is a perspective view of an exemplary vehicle 1000 in accordance with one embodiment. Here, some of the components discussed with respect to Figure 10 and earlier embodiments are shown. As illustrated and previously discussed, vehicle 1000 may have cameras, such as camera 1106 mounted on the rearview mirror, cameras (not shown) mounted on the front fenders, cameras (not shown) mounted on the side mirrors, and a rear camera (not shown, but typically on the trunk, hatch, or rear bumper). Vehicle 1000 may also have a LIDAR 1104 for detecting objects and measuring distances to those objects; LIDAR 1104 is typically mounted on the roof, however, if there are multiple LIDAR units 1104, they may be oriented around the front, rear, and sides of the vehicle. Vehicle 1000 may have various other location-related systems, such as a GNSS receiver 1070 (typically in the shark fin unit located at the rear of the roof as indicated), various wireless transceivers 1102 (such as WAN, WLAN, V2X; typically but not necessarily in the shark fin), a radar 1108 (typically in the front bumper), and sonar 1110 (typically on the sides of the vehicle if present). There may also be various wheel 1112 and driveline sensors, such as tire pressure sensors, accelerometers, gyroscopes, and wheel rotation detection and / or counters. In one embodiment, the distance measurements and relative positions determined via various sensors (such as LIDAR, radar, cameras, GNSS, and sonar) may be combined with vehicle size and shape information and information about the sensor locations to determine the distances and relative positions between the surfaces of different vehicles, such that the distance or vector between a sensor and another vehicle or between two different sensors (such as two GNSS receivers) is incrementally increased to account for the sensor positioning on each vehicle. Thus, the precise GNSS distance and vector between two GNSS receivers will need to be modified based on the relative positions of the respective vehicle surfaces to the GNSS receivers. For example, when determining the distance between the front bumper of a following vehicle and the rear bumper of a leading vehicle, the distance will need to be adjusted based on the distance between the GNSS receiver on the following vehicle and the front bumper and the distance between the GNSS receiver on the leading vehicle and the rear bumper of the leading vehicle. For example, the distance between the rear bumper of the leading vehicle and the front bumper of the following vehicle is the relative distance between the two GNSS receivers minus the distance from the GNSS receiver on the following vehicle to the front bumper and minus the distance from the GNSS receiver on the leading vehicle to the rear bumper. It is recognized that this list is not intended to be limiting, and Figure 11 is intended to provide exemplary locations of various sensors in an embodiment of vehicle 1000.

[0111] It will be apparent to those skilled in the art that substantial variations can be made in accordance with specific requirements. For example, customized hardware can also be used, and / or specific elements can be implemented in hardware, software (including portable software such as applets, etc.), or both. Further, connections to other computing devices (such as network input / output devices) can be employed.

[0112] Referring to the drawings, components that can include a memory (e.g., Figure 10 memory 1060) can include a non-transitory machine-readable medium. As used herein, the terms "machine-readable medium" and "computer-readable medium" refer to any storage medium that participates in providing data that causes a machine to operate in a particular manner. In the embodiments provided above, various machine-readable media may be involved in providing instructions / code for execution to a processing unit and / or other devices. Additionally or alternatively, the machine-readable medium can be used to store and / or carry such instructions / code. In many implementations, the computer-readable medium is a physical and / or tangible storage medium. Such media can take many forms, including but not limited to non-volatile media, volatile media, and transmission media. Common forms of computer-readable media include, for example: magnetic and / or optical media, any other physical media with a hole pattern, RAM, PROM, EPROM, FLASH-EPROM, any other memory chip or cartridge, the carrier wave described below, or any other medium from which a computer can read instructions and / or code.

[0113] The methods, systems, and devices discussed herein are examples. Various procedures or components may be appropriately omitted, substituted, or added in each embodiment. For example, the features described with reference to certain embodiments can be combined in various other embodiments. Different aspects and elements of the embodiments can be combined in a similar manner. The various components of the drawings provided herein can be embodied in hardware and / or software. Moreover, technology evolves, and thus many elements are examples that do not limit the scope of the present disclosure to those specific examples.

[0114] For reasons of general usage, it has proven convenient at times to refer to such signals as bits, information, values, elements, symbols, characters, variables, terms, quantities, numbers, etc. However, it should be understood that all such or similar terms are to be associated with appropriate physical quantities and are merely convenience labels. Unless specifically stated otherwise, as is apparent from the above discussion, it should be appreciated that throughout this specification, discussions using terms such as "processing", "computing", "calculating", "determining", "ascertaining", "identifying", "associating", "measuring", "performing", etc. refer to the actions or processes of a specific apparatus, such as a special purpose computer or similar special purpose electronic computing device. Thus, in the context of this specification, a special purpose computer or similar special purpose electronic computing device can manipulate or transform signals that are typically represented as physical, electronic, electrical, or magnetic quantities within the memory, registers, or other information storage devices, transmission devices, or display devices of the special purpose computer or similar special purpose electronic computing device.

[0115] As used herein, the terms "and" and "or" may include various meanings that also are expected to depend at least in part upon the context in which such terms are used. Generally, "or" if used in connection with a list, such as A, B, or C, is intended to mean A, B, and C (here used in the inclusive sense) as well as A, B, or C (here used in the exclusive sense). Additionally, the term "one or more" as used herein can be used to describe any feature, structure, or characteristic in the singular or can be used to describe some combination of features, structures, or characteristics. However, it should be noted that this is merely illustrative and the claimed subject matter is not limited to this example. Further, the term "at least one of" if used in connection with a list, such as A, B, or C, can be interpreted to mean any combination of A, B, and / or C, such as A, AB, AA, AAB, AABBCCC, etc.

[0116] A number of embodiments have been described and various modifications, alternative constructions, and equivalents can be used without departing from the spirit of the disclosure. For example, the above elements can be merely components of a larger system, where other rules may take precedence over or otherwise modify the application of the various embodiments. Additionally, several steps can be taken before, during, or after considering the above elements. Accordingly, the above description does not limit the scope of the disclosure.

Claims

1. A method for message selection and prioritization at a host vehicle (HV), the method comprising: Wirelessly receiving messages from a plurality of remote vehicles (RVs); Determining a first subset of the plurality of RVs to process the messages from the first subset, wherein the first subset is determined at least in part based on: The respective positions of each RV relative to the HV, One or more road conditions, and One or more operating constraints of the HV; and For each message received from an RV in the first subset, determining a priority for the respective message at least in part based on an indication of the remaining delay budget for the respective message, wherein: The priority for the respective message determines the order in which the content of the respective message will be processed by the HV; and An indication of the remaining delay budget for the respective message is received together with the respective message.

2. The method of claim 1, wherein determining the first subset of the plurality of RVs comprises: Defining a plurality of subsets of the plurality of RVs, wherein each subset of the plurality of subsets includes a different number of RVs from the plurality of RVs; And Selecting the first subset from the plurality of subsets based on the one or more operating constraints.

3. The method of claim 2, wherein defining each subset of the plurality of subsets is at least in part based on the one or more road conditions.

4. The method of claim 1, wherein determining the priority for the respective message comprises: Obtaining an indication of the remaining delay budget for the respective message at the radio layer of the HV; And Providing an indication of the remaining delay from the radio layer to the application layer of the HV.

5. The method of claim 4, wherein providing an indication of the remaining delay comprises providing a modified indication of the remaining delay to account for (i) the delay of the radio layer and (ii) over-the-air (OTA) delay.

6. The method of claim 4, wherein the radio layer of the HV obtains an indication of the remaining delay budget for the respective message via a physical sidelink control channel (PSCCH) for the respective message.

7. The method of claim 1, wherein the messages include vehicle-to-everything (V2X) basic safety messages (BSMs).

8. The method of claim 1, wherein the one or more road conditions of the road on which the HV is located include: The number of lanes of the road, The current lane of the HV, The speed limit of the road, Road hazards, Weather conditions, The curvature of the road, The speed of the HV, The heading of the HV, or The trajectory of one or more of the plurality of RVs, Or any combination thereof.

9. The method of claim 1, wherein the one or more operating constraints of the HV include: Message processing capabilities, Thermal constraints, Concurrency constraints, Or any combination thereof.

10. The method of claim 1, wherein determining the priority for the respective message is performed by the radio layer of the HV, the application layer of the HV, or both.

11. The method according to claim 1, further comprising filtering out the messages from the RVs in the plurality of RVs that are not in the first subset, wherein the filtering is performed by the radio layer of the HV, the application layer of the HV, or both.

12. An apparatus for message selection and prioritization at a host vehicle (HV), the apparatus comprising: One or more wireless transceivers; A memory; And One or more processors communicatively coupled to the one or more wireless transceivers and the memory and configured to: Receive messages from a plurality of remote vehicles (RVs) via the one or more wireless transceivers; Determine a first subset of the plurality of RVs to process the messages from the first subset, wherein the first subset is determined at least in part based on: The respective positions of each RV relative to the HV, One or more road conditions, and One or more operating constraints of the HV; and For each message received from an RV in the first subset, determine a priority for the respective message at least in part based on an indication of the remaining delay budget for the respective message, wherein: The priority for the respective message determines the order in which the content of the respective message will be processed by the HV; and An indication of the remaining delay budget for the respective message is received together with the respective message.

13. The device according to claim 12, wherein, To determine the first subset of the plurality of RVs, the one or more processors are configured to: Define a plurality of subsets of the plurality of RVs, wherein each subset of the plurality of subsets includes a different number of RVs from the plurality of RVs; And Select the first subset from the plurality of subsets based on the one or more operating constraints.

14. The apparatus according to claim 13, wherein the one or more processors are configured to define each subset of the plurality of subsets at least in part based on the one or more road conditions.

15. The apparatus according to claim 12, further comprising a radio layer and an application layer, wherein to determine the priority for the respective message: The radio layer is configured to obtain an indication of the remaining delay budget for the respective message; and The radio layer is configured to provide an indication of the remaining delay to the application layer.

16. The device according to claim 15, wherein, To provide an indication of the remaining delay, the radio layer is configured to provide a modified indication of the remaining delay to account for (i) the delay of the radio layer and (ii) over-the-air (OTA) delay.

17. The apparatus according to claim 15, wherein the radio layer is configured to obtain an indication of the remaining delay budget for the respective message via a physical sidelink control channel (PSCCH) for the respective message.

18. The apparatus according to claim 15, wherein the radio layer is implemented by the one or more transceivers, and the application layer is implemented by the one or more processors.

19. The device according to claim 15, wherein the radio layer, the application layer, or both are configured to determine the priority for the corresponding message.

20. The device according to claim 15, wherein the radio layer, the application layer, or both are configured to filter out the messages from the RVs in the plurality of RVs that are not in the first subset.

21. A device comprising: means for wirelessly receiving messages from a plurality of remote vehicles (RVs); means for determining a first subset of the plurality of RVs to process the messages from the first subset, wherein the first subset is determined at least in part based on: the respective positions of each RV relative to a host vehicle (HV), one or more road conditions, and one or more operating constraints of the HV; and means for determining, for each message received from an RV in the first subset, a priority for the corresponding message at least in part based on an indication of a remaining delay budget for the corresponding message, wherein: the priority for the corresponding message determines the order in which the content of the corresponding message will be processed by the HV; and the indication of the remaining delay budget for the corresponding message is received together with the corresponding message.

22. The device according to claim 21, wherein the means for determining the first subset of the plurality of RVs comprises: means for defining a plurality of subsets of the plurality of RVs, wherein each subset of the plurality of subsets includes a different number of RVs from the plurality of RVs; and means for selecting the first subset from the plurality of subsets based on the one or more operating constraints.

23. The device according to claim 21, wherein the means for determining the priority for the corresponding message comprises: means for obtaining, at a radio layer of the HV, an indication of a remaining delay budget for the corresponding message; and means for providing, from the radio layer to an application layer of the HV, an indication of the remaining delay.

24. The device according to claim 23, wherein the means for providing the indication of the remaining delay comprises means for providing a modified indication of the remaining delay to account for (i) the delay of the radio layer and (ii) over-the-air (OTA) delay.

25. The device according to claim 21, wherein the means for determining the priority for the corresponding message comprises means for implementing the radio layer of the HV, the application layer of the HV, or both.

26. The device according to claim 21, further comprising means for filtering out the messages from the RVs in the plurality of RVs that are not in the first subset, wherein the means for filtering comprises means for implementing the radio layer of the HV, the application layer of the HV, or both.

27. A non-transitory computer-readable medium having stored thereon instructions for message selection and prioritization at a host vehicle (HV), wherein the instructions, when executed by one or more processors, cause the one or more processors to: Wirelessly receive messages from multiple remote vehicles (RVs); Determine a first subset of the multiple RVs to process the messages from the first subset, wherein the first subset is determined at least in part based on: The respective positions of each RV relative to the HV, One or more road conditions, and One or more operating constraints of the HV; and For each message received from an RV in the first subset, determine a priority for the respective message at least in part based on an indication of the remaining delay budget for the respective message, wherein: The priority for the respective message determines the order in which the content of the respective message will be processed by the HV; and The indication of the remaining delay budget for the respective message is received together with the respective message.

28. The non-transitory computer-readable medium of claim 27, wherein the instructions for causing the one or more processors to determine the first subset of the multiple RVs further comprise instructions for causing the one or more processors to perform the following operations: Define multiple subsets of the multiple RVs, wherein each subset of the multiple subsets includes a different number of RVs from the multiple RVs; and Means for selecting the first subset from the multiple subsets based on the one or more operating constraints.

29. The non-transitory computer-readable medium of claim 27, wherein the instructions for causing the one or more processors to determine the priority for the respective message further comprise instructions for causing the one or more processors to perform the following operations: Obtain an indication of the remaining delay budget for the respective message at the radio layer of the HV; and Provide an indication of the remaining delay from the radio layer to the application layer of the HV.

30. The non-transitory computer-readable medium of claim 27, wherein the instructions, when executed by the one or more processors, further cause the one or more processors to filter out the messages from RVs among the multiple RVs that are not in the first subset at the radio layer of the HV, the application layer of the HV, or both.

Images