Intersection Trajectory Determination and Messaging

By determining intersection trajectories and segmenting intersections for vehicles using CV2X messaging, the solution addresses the inefficiencies in current intersection management systems, enhancing traffic flow and reducing delays at complex intersections.

JP7603689B2Active Publication Date: 2024-12-20QUALCOMM INC
View PDF 6 Cites 0 Cited by

Patent Information

Application Number
JP2022535666
Authority / Receiving Office
JP · JP
Patent Type
Patents
Current Assignee / Owner
Priority Date
2019-12-20
Filing Date
2020-12-15
Publication Date
2024-12-20
Estimated Expiration
2040-12-15

AI Technical Summary

Technical Problem

Current intersection management messaging technologies for autonomous and semi-autonomous vehicles are ineffective in providing the necessary information for effective intersection management, especially at complex intersections, failing to account for different vehicle types and intersection geometries.

Method used

The proposed solution involves determining pre- or real-time intersection trajectories based on vehicle characteristics and intersection geometry, and communicating these trajectories using CV2X messaging, which includes segmenting the intersection into track lanes and providing information on obstructed entry and exit points to ensure efficient vehicle passage.

Benefits of technology

This approach enables effective intersection management by minimizing vehicle obstruction and optimizing traffic flow, reducing travel time and fuel consumption by providing vehicles with precise trajectory information before arrival.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure 0007603689000003
    Figure 0007603689000003
  • Figure 0007603689000004
    Figure 0007603689000004
  • Figure 0007603689000005
    Figure 0007603689000005
Patent Text Reader

Abstract

Techniques are disclosed for advance or real-time intersection trajectory determination of a vehicle and corresponding messaging of the trajectory determination. The trajectory determination may be based on vehicle static characteristics, vehicle dynamic characteristics, and / or intersection geometry. Trajectory messages, which may be communicated using CV2X, may not only indicate the trajectory, but may also (optionally) indicate which intersection entry and exit points the vehicle will intercept over the vehicle's traversal path along the trajectory.
Need to check novelty before this filing date? Find Prior Art

Description

[Technical field]

[0001] Claiming priority This patent application claims the benefit of and priority to non-provisional application Ser. No. 16 / 723,719, entitled “INTERSECTION TRAJECTORY DETERMINATION AND MESSAGING,” filed Dec. 20, 2019, which is assigned to the assignee of the present application and is expressly incorporated herein by reference. [Background technology]

[0002] For autonomous and semi-autonomous vehicles, vehicle maneuvering and path planning are determined by the vehicle environment. The environment includes surrounding attributes such as vehicles, objects, and obstacles. Cellular vehicle-to-everything (CV2X) is a communication standard for exchanging information about a vehicle's environment. CV2X can include communication between CV2X-enabled vehicles and between CV2X-enabled vehicles and other CV2X-enabled entities such as infrastructure-based devices (commonly called road-side units (RSUs)), pedestrians, cyclists, or other road users. CV2X can use cellular-based communications such as Long Term Evolution (LTE) cellular technology, Fifth Generation (5G) cellular technology, and / or other cellular technologies in a direct communication mode as defined by the 3rd Generation Partnership Project (3GPP).

[0003] Traffic messaging technologies such as CV2X can be particularly useful for traffic intersection management, for both autonomous and non-autonomous vehicles. For example, with such management, vehicles can pass through an intersection without stopping or with reduced delays, thus reducing travel time and fuel consumption. Problematically, current solutions for intersection management messaging are ineffective in providing the information needed for effective intersection management, especially for more complex intersections. Summary of the Invention [Means for solving the problem]

[0004] The techniques described herein address these and other issues by providing advance or real-time intersection trajectory determination for a vehicle and corresponding messaging of the trajectory determination. The trajectory determination may be based on vehicle static characteristics, vehicle dynamic characteristics, and / or intersection geometry. Trajectory messages, which may be communicated using CV2X, may not only indicate the trajectory, but may also (optionally) indicate which intersection entry and exit points the vehicle will obstruct over the vehicle's traversal path along the trajectory.

[0005] An example method of communicating information for a vehicle's traversal through a traffic intersection according to the present description comprises obtaining information regarding the geometry of the intersection and determining a proposed route for the vehicle through the intersection from a predetermined one of one or more entrance points of the intersection to a predetermined one of one or more exit points of the intersection based at least in part on one or more characteristics of the vehicle, the geometry of the intersection, the one or more entrance points, and the one or more exit points. The method further comprises wirelessly transmitting a message indicating the proposed route.

[0006] An exemplary device for communicating information for a vehicle's traversal through a traffic intersection according to the present description comprises a wireless communication interface, a memory, and one or more processing units communicatively coupled to the memory and the wireless communication interface. The one or more processing units are configured to obtain information regarding the geometry of the intersection and to determine a proposed route for the vehicle through the intersection from a predetermined one of one or more entrance points of the intersection to a predetermined one of one or more exit points of the intersection based at least in part on one or more characteristics of the vehicle, the geometry of the intersection, the one or more entrance points, and the one or more exit points. The one or more processing units are further configured to wirelessly transmit a message indicative of the proposed route via the wireless communication interface.

[0007] An example device according to the present description comprises means for obtaining information regarding the geometry of the intersection and means for determining a proposed route for a vehicle through the traffic intersection from a predetermined one of the one or more entrance points of the intersection to a predetermined one of the one or more exit points of the intersection based at least in part on one or more characteristics of the vehicle, the geometry of the intersection, the one or more entrance points, and the one or more exit points. The example device further comprises means for wirelessly transmitting a message indicative of the proposed route.

[0008] An exemplary non-transitory computer-readable medium according to the present description has instructions stored thereon for communicating information for a vehicle's traversal through a traffic intersection. The instructions, when executed by one or more processing units, cause the one or more processing units to obtain information regarding the geometry of the intersection and determine a proposed route for the vehicle through the intersection from a predetermined one of one or more entrance points of the intersection to a predetermined one of one or more exit points of the intersection based at least in part on one or more characteristics of the vehicle, the geometry of the intersection, the one or more entrance points, and the one or more exit points. The instructions, when executed by the one or more processing units, further cause the one or more processing units to wirelessly transmit a message indicative of the proposed route. [Brief description of the drawings]

[0009] [Figure 1A] FIG. 2 is an overhead view of a vehicle crossing path through a first type of intersection. [Figure 1B] FIG. 2 is an overhead view of a vehicle crossing path through a first type of intersection. [Figure 2A] FIG. 2 is an overhead view of a vehicle crossing path through a first type of intersection. [Figure 2B] FIG. 2 is an overhead view of a vehicle crossing path through a first type of intersection. [Figure 3A] FIG. 1 is an overhead view of vehicle crossing paths through different types of intersections. [Figure 3B] FIG. 1 is an overhead view of vehicle crossing paths through different types of intersections. [Figure 3C] FIG. 1 is an overhead view of vehicle crossing paths through different types of intersections. [Figure 4A] 1 illustrates an overhead view of an intersection through which a crossing vehicle is attempting to travel via a rail lane, according to one embodiment. [Figure 4B]FIG. 4B illustrates a conflict map that can be used to show how various paths from the entrance to the exit of the intersection shown in FIG. 4A may be obstructed as the crossing vehicle in FIG. 4A proceeds along the track lanes. [Figure 5A] FIG. 4C is an overhead view of a first segment of the rail lane of FIG. 4B, according to one embodiment. [Figure 5B] FIG. 5B illustrates a contention map for the first segment shown in FIG. 5A according to one embodiment. [Figure 6A] FIG. 4C is an overhead view of a second segment of the track lane of FIG. 4B, according to one embodiment. [Figure 6B] FIG. 6B illustrates a contention map for the second segment shown in FIG. 6A according to one embodiment. [Figure 7A] FIG. 4C is an overhead view of a third segment of the rail lane of FIG. 4B, according to one embodiment. [Figure 7B] FIG. 7B illustrates a contention map for the third segment shown in FIG. 7A according to one embodiment. [Figure 8] FIG. 1 is a flow diagram of a method for communicating information for traversing a vehicle through a traffic intersection, according to one embodiment. [Figure 9] FIG. 1 is a block diagram of one embodiment of a mobile computer system. [Figure 10] FIG. 1 is a block diagram of one embodiment of a fixed computer system. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0010] According to some exemplary implementations, similar reference symbols in various drawings indicate similar elements. In addition, multiple instances of an element may be indicated by a first number for the element followed by a letter or a hyphen and a second number. For example, multiple instances of element 110 may be indicated as 110-1, 110-2, 110-3, etc., or as 110-A, 110-B, 110-C, etc. When referring to such an element using only the first number, any instances of the element should be implicitly understood (e.g., element 110 in the previous example would refer to elements 110-1, 110-2, and 110-3, or elements 110-A, 110-B, and 110-C).

[0011] Certain exemplary embodiments are described herein with reference to the accompanying drawings, which form a part of this specification. Specific embodiments in which one or more aspects of the present disclosure may be practiced are described below, but other embodiments may be used and various modifications may be made without departing from the spirit of the scope of the disclosure or the appended claims.

[0012] As previously mentioned, intersection management using CV2X or similar messaging can provide significant benefits, but current proposals for intersection management messaging fail to provide an effective solution for real-world scenarios. For example, proposals may utilize existing messaging, such as defined by standards bodies such as the Society of Automotive Engineers (SAE) or the European Telecommunications Standards Institute (ETSI) Intelligent Transportation Systems, to grant access to vehicles to cross through an intersection. However, this may be an ineffective solution since multiple vehicles may be able to cross multiple paths through an intersection. More advanced solutions suggest discretizing the intersection into blocks that are observable by time. However, even these solutions fall short in providing sufficient information for effective intersection management to take into account different vehicle types, especially for complex (e.g., irregularly shaped) intersections. The embodiments provided herein for communicating information for vehicle crossings through a traffic intersection address these and other issues.

[0013] It should be noted that although only a few types of intersections are illustrated in the embodiments herein, the disclosed techniques are applicable to all types of intersections. Furthermore, as referred to herein, an intersection's entrance "point" and exit "point" are locations at which a vehicle may enter or exit the intersection, respectively. Additionally, as used herein, the term "traffic entity" is used to refer to a vehicle, RSU, or other system (e.g., computer server, etc.) used to communicate information (e.g., using CV2X messaging) for traffic management.

[0014] 1A and 1B are overhead views of an intersection 100 illustrating how crossing vehicles (110-A and 110-B, collectively and generally referred to herein as crossing vehicles 110) may navigate the intersection 100 in different ways (by traveling along different respective crossing paths 120), thereby affecting traffic at the intersection 100 in different ways. In the example shown in FIGS. 1A and 1B, the intersection 100 comprises a roundabout (i.e., a rotary) with various points of entry and exit.

[0015] 1A , a first crossing vehicle 110-A comprises an automobile traveling along a first crossing path 120-A from an entrance point to an exit point. Because the first crossing vehicle 110-A is relatively small and maneuverable, it is able to navigate to the first crossing path 120-A without impeding access to the intersection 100 by other vehicles 140 at other points of entrance.

[0016] In contrast, the second crossing vehicle 110-B shown in FIG. 1B has many different effects on the intersection 100. Although crossing from the same entry and exit points as the first crossing vehicle 110-A, the second crossing vehicle 110-B comprises a much larger articulated vehicle (e.g., a semi-trailer truck with multiple semi-trailers). Thus, the second crossing vehicle 110-B takes a significantly different crossing path 120-B than the first crossing vehicle 110-A. As can be seen, the crossing path 120-B of the second crossing vehicle 110-B may end up blocking access to the intersection 100 for other vehicles 140.

[0017] Figures 2A and 2B are overhead views of an intersection 100 and first and second crossing vehicles 110, similar to the example shown in Figures 1A and 1B. However, here the entry and exit points are different, illustrating how lanes within the intersection 100 may be affected by the traversal of the crossing vehicle 110 through the intersection 100.

[0018] 2A , a first crossing vehicle 110-A (again, a relatively small, maneuverable automobile) can traverse through the intersection 100 along a first traversal path 220-A without obstructing access to the intersection 100 for other vehicles 140. Due to the size and maneuverability of the first traversing vehicle 110-A, the traversal path 220-A is strictly within the outer lane 260 of the intersection 100, leaving the inner lane 250 unobstructed, and thereby potentially accessible, for other vehicles 140.

[0019] However, while traveling along first traversal path 220-A, first crossing vehicle 110-A blocks entrance point 230 and exit point 240 of intersection 100. Thus, at some time while first crossing vehicle maneuvers through intersection 100 along first traversal path 220-A, exit point 240 is inaccessible to other vehicles 140 and entrance point 230 is blocked to any vehicles approaching entrance point 230.

[0020] 2B, the second traversal path 220-B of the second traversing vehicle 110-B requires additional consideration. The second traversal path 220-B not only blocks the exit point 240 and the entrance point 230 in the same manner as the first traversal path 220-A, but also blocks a portion of the inside lane 250. It may be further noted that due to the size, speed, and other characteristics of the second traversing vehicle 110-B, the second traversing vehicle 110-B may block the exit point 240 and the entrance point 230 for a longer period of time compared to the first traversing vehicle 110-A.

[0021] 3A-3C are additional perspective views of various types of intersections 300 illustrating how crossing vehicles can affect traffic at the intersection in various ways as they proceed along their crossing paths.

[0022] The intersection 300 shown in Figure 3A is a conventional grid-based intersection of two roads, where a crossing vehicle 305 is a large articulated vehicle traveling along a crossing path 310 through various portions of the intersection over a period of time. As can be seen, this may affect the possible crossing paths 315 of another vehicle 320 in different ways. That is, some possible crossing paths 315 may be available to the vehicle 320 at any time while the crossing vehicle 305 is traveling along the crossing path 310, while at least portions of other possible crossing paths 315 may be inaccessible for at least a portion of the time the crossing vehicle 305 is traveling along the crossing path 310.

[0023] 3B shows an intersection 325 with a roundabout, where a crossing vehicle 330 (also a large articulated vehicle) proceeds along a crossing path 335. However, a possible crossing path 340 is accessible to another vehicle 345. Thus, the other vehicle 345 may be able to proceed through the intersection 325 along the possible crossing path 340 at any time that the crossing vehicle 330 is proceeding along the crossing path 335.

[0024] 3C , the third intersection 350 comprises a non-grid intersection that is differentially affected by different traversing vehicles 360. A first traversing vehicle 360-1, a second traversing vehicle 360-2, and a third traversing vehicle 360-3 travel along a first traversal path 370-1, a second traversing path 370-2, and a third traversal path 370-3, respectively. Not only may the traversal paths 370 span over different portions of the intersection 350, but other characteristics (speed, size, etc.) of the different traversing vehicles 360 may also affect the intersection 350 differently.

[0025] With these issues in mind, embodiments can provide effective messaging for intersection management by determining traverse paths for vehicles to proceed through an intersection and communicating (e.g., using CV2X) messages that provide sufficient information to represent these determined traverse paths. This can be done in an efficient manner to help minimize the bandwidth used to communicate these messages. According to embodiments, various input parameters (in addition to entry and exit points) can be taken into account when determining traverse paths for crossing vehicles to proceed through an intersection.

[0026] According to some embodiments, input parameters for defining a traverse path through an intersection may include parameters related to the intersection geometry. The intersection geometry may include, for example, the number of lanes, such as lane widths for each of the roads in the intersection, the locations of each of the entry and exit points, and temporary features that may affect progression through the intersection. These temporary features may include, for example, construction zones, weather-related obstacles (e.g., snow drifts, ice slicks, etc.), other temporary obstacles (e.g., potholes, uneven lanes, etc.), and the like.

[0027] Techniques for representing intersection geometry may vary depending on the desired functionality. According to some embodiments, intersection geometry may be represented using classifications established by existing standards (e.g., SAE / ETSI standards) for representing various features (such as number of lanes and entrance / exit locations). In some embodiments, locations may be represented relative to a map. Also, references to "ETSI" herein refer to all relevant ETSI standards, including the ETSI Intelligent Transportation System (ETSI-ITS).

[0028] Since each vehicle occupies several portions of the intersection at any particular time depending on its static and dynamic characteristics, these static and dynamic characteristics of the crossing vehicles may additionally or alternatively be used as input parameters for determining the crossing path through the intersection. Static vehicle characteristics may include fixed physical features such as vehicle size and vehicle type. With respect to vehicle type, this may include whether the vehicle is a passenger car, a truck, an articulated truck including a trailer or towed cargo, etc. According to some embodiments, specific information about the vehicle may be communicated, including model and / or equipment type. Dynamic characteristics may include safe stopping distance, turning radius, acceleration, deceleration, and / or other variable features of the vehicle. Again, according to some embodiments, techniques for representing static and / or dynamic vehicle characteristics may use definitions set by existing standards.

[0029] Using these inputs, the traversing vehicle, RSU, or other traffic entity can determine a traversal path for the traversing vehicle through the intersection and create an intersection trajectory message (ITM) to communicate the proposed traversal path to other connected (CV2X) traffic entities. Furthermore, according to some embodiments, the traversal path can be segmented into multiple segments and respective "conflicts" can be determined to indicate which exit and entrance points may be blocked as the vehicle traverses each segment of the traversal path.

[0030] 4A and 4B help illustrate a baseline of how this can be done. FIG. 4A is an overhead view of an intersection 400 through which a crossing vehicle 410 is to proceed, with the entry and exit points listed as shown. Using the above inputs, the crossing vehicle 410 (or an RSU or other traffic entity) can determine a traverse path 420 for the crossing vehicle 410 through the intersection 400. More specifically, the crossing vehicle 410 can determine a track lane 430 that comprises an area of ​​the intersection 400 on which the crossing vehicle 410 will proceed as it crosses along the traverse path 420. FIG. 4B illustrates a corresponding conflict map that is used to show how access from an entry point of the intersection 400 to an exit point of the intersection 400 may be obstructed over the path of the crossing vehicle's proceeding along the traverse path 420, given the dimensions of the track lane.

[0031] An ITM can be created and transmitted to convey this information about the crossing path (including exit and entrance conflicts) prior to the arrival of the crossing vehicle 410 at the intersection 400, thereby enabling management of the intersection 400 (e.g., by the RSU controlling traffic through the intersection 400 or between the vehicles themselves). According to some embodiments, the ITM may do so by segmenting the intersection 400 along track lanes 430 and providing information about each of the segments, as shown in Figures 5A-7B.

[0032] 5A illustrates a first segment 510 of track lanes 430 of intersection 400 for a crossing vehicle 410. FIG 5B illustrates an entrance to exit path that is obstructed for other vehicles 520 when crossing vehicle 410 is in first segment 510. For example, crossing vehicle 410 is adjacent to exit 4, obstructing traversal through intersection 400 by other vehicles from entrance 2 or entrance 3 to exit 4. Additionally, path from entrance 2 to exit 3 is also obstructed.

[0033] 6A illustrates a second segment 610 of the track lane 430 of the intersection 400 for the crossing vehicle 410. Again, correspondingly, FIG. 6B illustrates the entrance to exit paths that are blocked for other vehicles when the crossing vehicle 410 is in the second segment 610. As shown, many paths are blocked because the crossing vehicle 410 is near the center of the intersection 400. This leaves only right turns available for other vehicles, i.e., entrance 2 to exit 1, entrance 3 to exit 2, and entrance 4 to exit 3.

[0034] Figure 7A illustrates the third segment 710 of the track lane 430 of the intersection 400 for a crossing vehicle 410. Figure 7B illustrates the corresponding entrance to exit paths that are blocked for other vehicles when the crossing vehicle 410 is in the third segment 610, where the blocked paths include all paths from entrance 3, as well as paths from entrance 4 to exit 1 and paths from entrance 4 to exit 2.

[0035] 5A-7B illustrate the track lanes 430 defined by three segments, the number of segments and the manner of segmentation may vary depending on the desired functionality. As with the track lanes 430 themselves, the segmentation may be based on, for example, intersection geometry, vehicle characteristics, and entry / exit points. Depending on the desired functionality, the segmentation may be very fine-grained (many segments) or coarse-grained (fewer segments). The optimal amount of segments may depend on the input characteristics of the particular intersection and the particular vehicle crossing.

[0036] According to some embodiments, the segments may be based at least in part on how the entry and exit points are obstructed. That is, as shown in FIGS. 5A-7B, the track lanes 430 may be segmented such that each segment has a different conflict map. In other words, the segments may be defined based on determining the track lanes 430 of the traversing vehicle 410 and how the exit and entry points are obstructed as the traversing vehicle 410 progresses along the traversal path 420. For each instance of the corresponding conflict map with changes as the traversing vehicle 410 progresses along the traversal path 420, a new segment of the track lanes 430 may be generated. Once the segments are determined, information about the segments, such as the arrival and departure of the traversing vehicle from each segment, may be determined, as described in more detail below.

[0037] As mentioned, determination of the track lanes 430, segments, and other information regarding a crossing vehicle's proposed crossing of the intersection 400 can be determined by a traffic entity (e.g., the crossing vehicle 410, or an RSU managing the intersection 400) prior to the crossing vehicle's arrival at the intersection 400. This information can be communicated to other entities at or near the intersection (e.g., from the RSU to the crossing vehicle 410, or vice versa) for intersection management.

[0038] The information contained in the ITM may vary depending on the desired functionality. In general, the ITM may include information regarding the crossing vehicle 410, the crossing path 420 (which may include rail lanes 430 within the intersection 400 and / or segments thereof), and the entry and exit points that will be obstructed as the crossing vehicle 410 travels along the crossing path 420. According to some embodiments, the contents of the ITM may be described as shown in Table 1. [Table 1]

[0039] For a rail lane 430 with n segments, as shown in Table 1, the ITM may include information about the requesting vehicle, a segment count, and information about each of the n segments. According to some embodiments, the ITM may use new data elements as well as existing data elements as defined by SAE and / or ETSI.

[0040] The information about the requesting vehicle may comprise sufficient information to identify the requesting vehicle (e.g., the vehicle requesting to cross an intersection) among other vehicles. This may include existing definitions for a requesting vehicle under SAE / ETSI and / or other information. In some embodiments, for example, this may include a Vehicle Identification Number (VIN) or other unique identifier, a vehicle description, etc.

[0041] The segment count may simply be an integer value n that indicates the number of segments contained in the ITM.

[0042] The data communicated for each of the n segments in the ITM may vary depending on the desired functionality. In some embodiments, the information for each segment is: A description of each segment; -Estimated time of arrival (ETA) for each crossing vehicle on each segment; The estimated time of departure (ETD) of the crossing vehicle from each segment, and May include an indication of which intersection entrance and exit points are obstructed during the time (from ETA to ETD) that the crossing vehicle is in each segment.

[0043] According to some embodiments, the intersection geometry may be determined using existing messages, such as the SAE J2735 MAP message. The segments may be defined as an overlay on a map of the intersection. According to some embodiments, the description of each segment may be done using existing constructs. One such example is the SAE GenericLane data field. Additional details regarding the information that may be conveyed in the ITM for each segment, according to one embodiment, are shown in Table 2. [Table 2]

[0044] As shown in the descriptions of the various data fields (DF) and data elements (DE) provided in Table 2, the ITM may include a large amount of information for each segment. This may include not only the previously mentioned information for each segment (segment description, ETA and ETD, and indication of blocked entry / exit points), but also several blocked entry points and / or blocked exit points when a traversing vehicle is in the respective segment. As one skilled in the art will appreciate, some of the DEs and DFs provided in Table 2 may correspond to DEs and DFs currently defined by relevant SAE and / or ETSI standards. (For example, DF_GenericLane may correspond to the data field GenericLane defined by SAE. DE_MinuteOfTheYear, DF_GenericLane, and / or DE_ApproachID may also correspond to data elements / data fields defined by SAE, along with equivalents defined by ETSI-ITS.) Thus, some embodiments may generate and communicate ITMs that utilize some or all of these existing standards-based definitions. That said, other embodiments may additionally or alternatively use proprietary definitions for these DE and DF.

[0045] As an example, the information shown in Table 1 and Table 2 can be applied to the example shown in Figures 5A-7B as follows: As the crossing vehicle 410 approaches the intersection 400, a traffic entity (e.g., the crossing vehicle 410 itself, or an RSU) can determine the crossing path 420 for the crossing vehicle 410, as well as the track lanes 430 and corresponding segments (first segment 510, second segment 610, and third segment 710).

[0046] As previously indicated, the traffic entity that creates and transmits the ITM communicating the traversal path 420 may comprise a vehicle that is about to cross the intersection (the crossing vehicle 410) or an infrastructure component that manages the intersection, such as an RSU (not shown) located near the intersection 400. When the ITM is created by the RSU, the RSU utilizes characteristics of the crossing vehicle 410, which may be received by a message such as a BSM or may be detected by the RSU, or both. (As one skilled in the art will appreciate, a BSM is a message periodically transmitted by a vehicle that conveys information about the vehicle, such as its size, speed, direction (or motion vector), whether it is towing a trailer, etc.) This information is known when the ITM is created by the crossing vehicle 410.

[0047] With this information about the crossing vehicle 410, a traffic entity can determine a crossing path 420. The crossing path 420 may be known in advance for a particular intersection 400 based on the vehicle classification of the crossing vehicle 410 and the geometry of the intersection 400. Alternatively, the crossing path 420 can be calculated in real time by a traffic entity based on the intersection geometry and vehicle characteristics.

[0048] Once the traversal path 420 is determined, the traffic entity can then create an ITM that includes an identifier for the traversing vehicle 410, a segment count of three, and information for each of the three segments. For each of the three segments, the ETA and ETD of each of the traversing vehicle 410 can be provided by Segment_ETA and Segment_ETD, respectively. The geometry of the segment can be conveyed using SegmentGeometry, and the entry and exit points can be provided by IntersectionIngress and IntersectionEgress, respectively. A per-segment conflict map can be conveyed by using DF_IngressAccessBlocked and DF_EgressAccessBlocked to indicate the entry and exit points blocked by each segment, respectively.

[0049] Once an ITM is created, the traffic entity that created the ITM can then transmit it to other traffic entities. In an embodiment in which the crossing vehicle 410 creates the ITM, the crossing vehicle 410 can transmit the ITM to the RSU and / or other nearby vehicles for intersection management by the RSU (if the intersection 400 is RSU-managed) or between the vehicles (if the intersection 400 is managed between the vehicles themselves).

[0050] In general, an ITM may be created and transmitted to traffic entities as a crossing vehicle approaches an intersection. According to some embodiments, this may mean that an ITM is created and transmitted (e.g., by either the crossing vehicle or the RSU) when the crossing vehicle is within a threshold distance of the intersection. This distance may vary from intersection to intersection and may be based on factors to help optimize bandwidth for traffic management (e.g., CV2X) communications for the intersection.

[0051] According to some embodiments, the timing of the creation and transmission of the ITM may additionally be based on the speed of the vehicle. That is, the ITM may be created and transmitted based on both the distance and speed of the vehicle and may indicate the time that the crossing vehicle may be at the intersection (or within a threshold distance to the intersection). According to some embodiments, the ITM may be created and transmitted prior to an established "time to collision." For example, a time to collision of 4 seconds is currently a well-known standard and may therefore be used in some embodiments. However, other embodiments may have the ITM created and transmitted using a longer or shorter time to collision. More generally, the creation and transmission of the ITM may be based on the required reaction time of other vehicles in or approaching the intersection. The reaction time may be determined by the vehicle speed and / or the distance to the intersection.

[0052] The ITM may comprise new information (e.g., track lane segmentation, blocked entry / exit points, etc.) and thus may be created and communicated independently of currently governing standards, although embodiments are not so limited. According to some embodiments, some or all of the content of the ITM may be incorporated into existing messages, such as those defined by SAE and / or ETSI. That is, one or more currently defined application layer messages, such as those defined by SAE or ETSI-ITS, such as signal request or response messages relating to intersections, may be modified, according to some embodiments, to include some or all of the information provided in the ITM.

[0053] FIG. 8 is a flow diagram of a method 800 for communicating information for a vehicle's crossing through a traffic intersection, according to one embodiment. The method 800 is intended to broadly incorporate techniques described in the previously described embodiments. Thus, the functions described in the blocks illustrated in FIG. 8 may be performed by the vehicle and / or another traffic entity (e.g., an RSU) communicatively coupled to the vehicle. More specifically, the functions of the method 800 may be performed by hardware and / or software components of the vehicle and / or traffic entity, such as a mobile computer system illustrated in FIG. 9 and / or a traffic entity computer illustrated in FIG. 10, both of which are described in more detail below.

[0054] The functions in block 805 comprise obtaining information regarding the geometry of the intersection. The geometry of the intersection may be obtained, for example, from a map that may be stored locally in the vehicle and / or other traffic entity and / or may be obtained from a map database. Updates regarding temporary traffic conditions at the intersection (e.g., stalled vehicles, closed lanes, etc.) may also be obtained. In some embodiments, these temporary traffic conditions may be attached to the map information regarding the intersection. The means for performing the functions in block 805 may comprise hardware and / or software components of a mobile computer system disposed on the vehicle, such as a bus 905, a processing unit 910, a memory 960, a wireless communication interface 930, and / or other components of the mobile computer system 900 shown in FIG. 9 and described in more detail below. Additionally or alternatively, the means for performing the functions in block 805 may comprise hardware and / or software components of a traffic entity computer, such as a bus 1005, a processing unit 1010, a storage device 1025, a working memory 1035, a communication subsystem 1030, and / or other components of a fixed computer system 1000 as shown in FIG. 10 and described in more detail below.

[0055] The function in block 810 comprises determining a proposed route for the vehicle through the intersection from a predetermined one of the one or more entrance points of the intersection to a predetermined one of the one or more exit points of the intersection based at least in part on one or more characteristics of the vehicle, the geometry of the intersection, the one or more entrance points, and the one or more exit points. As shown in the previously described embodiments, the proposed route for the vehicle may vary significantly depending on the geometry of the intersection (e.g., roundabout vs. grid-based intersection), the static characteristics of the vehicle (e.g., size, weight, articulation, etc.), and the dynamic characteristics of the vehicle (e.g., acceleration, safe stopping distance, turning radius, etc.). As mentioned, the characteristics of the vehicle may comprise vehicle size, vehicle type, vehicle model, whether the vehicle is towing a trailer or towed cargo, safe stopping distance, turning radius, acceleration, or deceleration, or any combination thereof. Additionally or alternatively, the one or more characteristics of the vehicle may be stored locally at the vehicle and / or other traffic entities and / or may be otherwise obtained by the vehicle and / or other traffic entities. The exit and entrance points may be provided by the vehicle's navigation system (or another traffic source having vehicle navigation information) to an entity that determines the vehicle's suggested route through the intersection.

[0056] As mentioned, the proposed route of the vehicle may be calculated by a traffic entity (e.g., the vehicle or RSU) depending on the desired functionality, or may be known in advance for the intersection depending on the vehicle characteristics. Thus, according to some embodiments, determining the proposed route of the vehicle through the intersection may comprise performing a real-time calculation to determine the proposed route of the vehicle, or looking up a pre-defined route (e.g., in a database or look-up table) to determine the proposed route. In the latter case, the information in the database or look-up table can be provided in the infrastructure component, pre-located in the vehicle (e.g., at the time of manufacture), or transmitted to the vehicle (e.g., via wireless communication).

[0057] The means for performing the functions in block 810 may comprise hardware and / or software components of a mobile computer system disposed on a vehicle, such as the bus 905, the processing unit 910, the memory 960, and / or other components of the mobile computer system 900 shown in Figure 9 and described in more detail below. Additionally or alternatively, the means for performing the functions in block 810 may comprise hardware and / or software components of a traffic entity computer, such as the bus 1005, the processing unit 1010, the storage device 1025, the working memory 1035, and / or other components of the fixed computer system 1000 shown in Figure 10 and described in more detail below.

[0058] At block 820, the function comprises wirelessly transmitting a message indicative of a proposed route. As noted in the above embodiments, the timing of the creation and dissemination of the message may be based on the vehicle's distance to the intersection and / or the vehicle's estimated time of arrival at the intersection. Thus, according to some embodiments, the method 800 may further comprise transmitting the message indicative of the proposed route in response to a triggering event, where the triggering event comprises a determination that the vehicle is within a threshold distance of the intersection, a determination that the vehicle arrives within a threshold distance of the intersection within a threshold amount of time, or both. In some embodiments, the triggering event may further be based on a determination that a second vehicle is within the intersection and / or some proximity of the vehicle, in which case the vehicle may choose to transmit the message at an earlier point in time to help ensure control of the intersection prior to the arrival of one or both of the vehicles at the intersection. Additionally or alternatively, the message indicative of the proposed route may comprise an application layer message such as defined by SAE or ETSI-ITS.

[0059] The means for performing the functions in block 820 may comprise hardware and / or software components of a mobile computer system disposed on a vehicle, such as the bus 905, the processing unit 910, the memory 960, the wireless communication interface 930, and / or other components of the mobile computer system 900 shown in Figure 9 and described in more detail below. Additionally or alternatively, the means for performing the functions in block 810 may comprise hardware and / or software components of a traffic entity computer, such as the bus 1005, the processing unit 1010, the storage device 1025, the working memory 1035, the wireless communication interface 1033, and / or other components of the fixed computer system 1000 shown in Figure 10 and described in more detail below.

[0060] As noted in the embodiments described above, the content of the message may vary depending on the desired functionality. According to some embodiments, for example, the message may include obstruction information. More specifically, the message may include entrance and exit obstruction information indicating which of the one or more entrance points and which of the one or more exit points are obstructed by the vehicle during the time period that the vehicle is expected to traverse through the intersection on the proposed route.

[0061] According to some embodiments, the proposed route may be segmented. The segments of the proposed route may comprise segments of track lanes that will be occupied by the vehicle at various times as the vehicle progresses along the traverse route. Thus, according to some embodiments, the message includes information indicative of one or more segments of the proposed route. Furthermore, for each segment, the message may include an arrival time (e.g., ETA) of the vehicle at the respective segment, and a departure time (e.g., ETD) of the vehicle from the respective segment. Furthermore, according to some embodiments, the entrance and exit obstruction information may indicate, for each segment, which of the one or more entrance points and which of the one or more exit points are obstructed by the vehicle between the arrival time of the vehicle at the respective segment and the departure time of the vehicle from the respective segment.

[0062] As previously mentioned, the segments of the track lane may vary depending on the desired functionality. For example, according to some embodiments, the one or more segments may comprise a plurality of segments, where two of the plurality of segments overlap. According to some embodiments, the segments themselves may be determined as part of the method 800. Thus, in such an embodiment, the method 800 may further comprise determining a respective segment geometry for each of the one or more segments. In some embodiments, the geometry for each of the one or more segments may be based at least in part on one or more static characteristics of the vehicle, one or more dynamic characteristics of the vehicle, the geometry of the intersection, one or more temporal characteristics of the intersection, a predetermined entry point of one or more entry points, or a predetermined exit point of one or more exit points, or any combination thereof.

[0063] As noted, method 800 may be performed by a vehicle and / or a separate traffic entity, such as an RSU that manages an intersection. Thus, according to some embodiments, the determination of the proposed route and the wireless transmission of the message indicative of the proposed route are performed by a component onboard the vehicle, such as a mobile computer system. In other embodiments, the determination of the proposed route and the wireless transmission of the message indicative of the proposed route are performed by a component of the RSU, such as a traffic entity computer.

[0064] FIG. 9 illustrates one embodiment of a mobile computer system 900 that may be utilized as described herein above. For example, the mobile computer system 900 may comprise a vehicle computer system that manages one or more systems related to navigation and / or automated driving of the vehicle and is also used to communicate with other on-board systems and / or other traffic entities. The mobile computer system 900 may be used to perform one or more of the functions of the method 800 of FIG. 8. It should be noted that FIG. 9 is intended only to provide a generalized illustration of various components, any or all of which may be utilized as appropriate. It may be noted that in some instances, the components illustrated by FIG. 9 may be localized in a single physical device and / or distributed among various networked devices that may be disposed at different physical locations on the vehicle.

[0065] A mobile computer system 900 is shown comprising hardware elements that may be electrically coupled (or otherwise in communication as appropriate) via a bus 905. The hardware elements may include a processing unit 910, which may include, but is not limited to, one or more general purpose processors, one or more special purpose processors (such as digital signal processing (DSP) chips, graphics acceleration processors, application specific integrated circuits (ASICs), etc.), and / or other processing structures or processing means. As shown in FIG. 9, some embodiments may have a separate digital signal processor (DSP) 920 depending on the desired functionality. Location determination and / or other determinations based on wireless communication may be performed in the processing unit 910 and / or in a wireless communication interface 930 (described below). The mobile computer system 900 may also include one or more input devices 970 (e.g., touch screens, touch pads, microphones, buttons, dials, switches, etc.), which may include devices related to a user interface, and / or devices related to navigation, autonomous driving, etc. Similarly, one or more output devices 915 may relate to interacting with a user (e.g., via a display, light emitting diodes (LEDs), speakers, etc.) and / or devices related to navigation, autonomous driving, etc.

[0066] The mobile computer system 900 may also include a wireless communication interface 930, which may comprise, but is not limited to, a modem, a network card, an infrared communication device, a wireless communication device, and / or a chipset (such as a Bluetooth device, an IEEE 802.11 device, an IEEE 802.15.4 device, a Wi-Fi device, a WiMAX device, a WAN device, and / or various cellular devices), which may enable the mobile computer system 900 to communicate to other traffic entities (e.g., RSUs, other vehicles, etc.). Communication may be performed via one or more wireless communication antennas 932 that transmit and / or receive wireless signals 934.

[0067] The mobile computer system 900 may further include sensors 940. The sensors 940 may comprise, but are not limited to, one or more inertial sensors and / or other sensors (e.g., accelerometers, gyroscopes, cameras, magnetometers, altimeters, microphones, proximity sensors, light sensors, barometers, etc.). The sensors 940 may be used to determine certain real-time characteristics of the vehicle, such as, for example, location, speed, acceleration, etc.

[0068] An embodiment of the mobile computer system 900 may also include a GNSS receiver 980 capable of receiving signals 984 from one or more GNSS satellites using an antenna 982 (which may be the same as antenna 932). Positioning based on GNSS signal measurements may be utilized to determine the current location of the vehicle, which may be used as a trigger to determine and / or transmit an ITM as described herein, as described above. The GNSS receiver 980 may extract a position of the mobile computer system 900 using conventional techniques from GNSS satellites of a GNSS system, such as the Global Positioning System (GPS) and / or similar systems.

[0069] The mobile computer system 900 may further include and / or be in communication with memory 960. Memory 960 may include, but is not limited to, local and / or network accessible storage, disk drives, drive arrays, optical storage devices, solid-state storage devices such as random access memory (RAM) and / or read-only memory (ROM) that may be programmable, flash updatable, and the like. Such storage devices may be configured to implement any suitable data storage system, including, but not limited to, various file systems, database structures, and the like.

[0070] The memory 960 of the mobile computer system 900 may also comprise software elements (not shown in FIG. 9 ), including an operating system, device drivers, executable libraries, and / or other code, such as one or more application programs, which may comprise computer programs provided by various embodiments and / or may be designed to implement methods and / or configure systems provided by other embodiments, as described herein. By way of example only, one or more procedures described with respect to the methods described above may be implemented as code and / or instructions in the memory 960 executable by the mobile computer system 900 (and / or a processing unit 910 or DSP 920 within the mobile computer system 900). In one aspect, such code and / or instructions can then be used to configure and / or adapt a general-purpose computer (or other device) to perform one or more operations in accordance with the methods described.

[0071] FIG. 10 illustrates an embodiment of a fixed computer system 1000 that may be utilized and / or incorporated within one or more components of a fixed traffic entity, such as an RSU or other fixed infrastructure device. FIG. 10 provides a schematic diagram of an embodiment of a fixed computer system 1000 that can perform methods provided by various other embodiments, such as the method described with respect to FIG. 8. It should be noted that FIG. 10 is intended only to provide a generalized illustration of various components, any or all of which may be utilized as appropriate. Thus, FIG. 10 broadly illustrates how individual system elements may be implemented in a relatively separated or relatively more integrated manner. In addition, it can be noted that the components illustrated by FIG. 10 can be localized in a single device and / or distributed among various networked devices that may be disposed in different physical or geographical locations.

[0072] A fixed computer system 1000 is shown comprising hardware elements that may be electrically coupled (or otherwise in communication as appropriate) via a bus 1005. The hardware elements may include a processing unit 1010, which may include, but is not limited to, one or more general purpose processors, one or more special purpose processors (such as digital signal processing chips, graphics acceleration processors, etc.), and / or other processing structures that may be configured to perform one or more of the methods described herein, including the methods described with respect to FIG. 10. The fixed computer system 1000 may also include one or more input devices 1015, which may include, but is not limited to, a mouse, a keyboard, a camera, a microphone, etc., and one or more output devices 1020, which may include, but is not limited to, a display device, a printer, etc.

[0073] Fixed computer system 1000 may further include (and / or be in communication with) one or more non-transitory storage devices 1025, which may comprise, but are not limited to, local and / or network-accessible storage, and / or may include, but are not limited to, disk drives, drive arrays, optical storage devices, solid-state storage devices such as RAM and / or ROM that may be programmable, flash-updateable, etc. Such storage devices may be configured to implement any suitable data storage system, including, but not limited to, various file systems, database structures, etc.

[0074] Fixed computer system 1000 may also include a communications subsystem 1030, which may include support for wireline and / or wireless communications technologies, managed and controlled (in some embodiments) by a wireless communications interface 1033. Communications subsystem 1030 may include a modem, a network card (wireless or wired), an infrared communications device, a wireless communications device, and / or a chipset, etc. Communications subsystem 1030 may include one or more input and / or output communications interfaces, such as wireless communications interface 1033, to enable data and signaling to be exchanged with networks, vehicles and other mobile devices, other computer systems, and / or any other electronic devices described herein.

[0075] In many embodiments, the fixed computer system 1000 further comprises a working memory 1035, which may include a RAM device and / or a ROM device. The software elements shown as being localized in the working memory 1035 may include other code, such as an operating system 1040, device drivers, executable libraries, and / or applications 1045, which may comprise computer programs provided by various embodiments and / or may be designed to implement methods and / or configure systems provided by other embodiments, as described herein. By way of example only, one or more procedures described with respect to the methods described above, such as the method described with respect to FIG. 8, may be implemented as code and / or instructions stored (e.g., temporarily) in the working memory 1035 and executable by a computer (and / or a processing unit therein, such as the processing unit 1010), and in one aspect, such code and / or instructions can then be used to configure and / or adapt a general-purpose computer (or other device) to perform one or more operations according to the described methods.

[0076] A set of these instructions and / or code may be stored on a non-transitory computer-readable storage medium, such as storage device 1025 described above. In some cases, the storage medium may be incorporated within a computer system, such as fixed computer system 1000. In other embodiments, the storage medium may be separate from the computer system and / or provided in an installation package (e.g., a removable medium such as an optical disk), such that the storage medium may be used to program, configure, and / or adapt a general-purpose computer with the instructions / code stored thereon. These instructions may take the form of executable code executable by fixed computer system 1000 and / or may take the form of source and / or installable code that, upon compilation and / or installation on fixed computer system 1000 (e.g., using any of a variety of commonly available compilers, installation programs, compression / decompression utilities, etc.), then takes the form of executable code.

[0077] It will be apparent to those skilled in the art that substantial variations may be made according to particular requirements. For example, customized hardware may also be used and / or particular elements may be implemented in hardware, software (including portable software such as applets, etc.), or both. Furthermore, connection to other computing devices, such as network input / output devices, may be employed.

[0078] With reference to the accompanying drawings, components that may include memory may include non-transitory machine-readable media. As used herein, the terms "machine-readable medium" and "computer-readable medium" refer to any storage medium that participates in providing data to cause a machine to operate in a specific manner. In the embodiments provided above, various machine-readable media may participate in providing instructions / code to a processing unit and / or other devices for execution. Additionally or alternatively, machine-readable media may be used to store and / or transport such instructions / code. In many implementations, the computer-readable medium is a physical and / or tangible storage medium. Such media may 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 media and / or optical media, any other physical media with a pattern of holes, RAM, PROM, EPROM, FLASH-EPROM, any other memory chip or cartridge, a carrier wave as described below, or any other medium from which a computer can read instructions and / or code.

[0079] The methods, systems, and devices described herein are examples. Various embodiments may omit, substitute, or add various procedures or components, as appropriate. For example, features described with respect to some embodiments may be combined in various other embodiments. Different aspects and elements of the embodiments may be combined in a similar manner. Various components of the drawings provided herein may be embodied in hardware and / or software. Also, technology evolves, and thus many of the elements are examples that do not limit the scope of the disclosure to those specific examples.

[0080] It has proven convenient at times, primarily for reasons of common usage, to refer to such signals as bits, information, values, elements, symbols, characters, variables, terms, numbers, numeric values, or the like. It should be understood, however, that all of these or similar terms are to be associated with the appropriate physical quantities and are merely convenient labels. Unless otherwise indicated, and as is apparent from the above description, it will be appreciated that throughout this specification descriptions utilizing terms such as "processing," "computing," "calculating," "determining," "determining," "identifying," "associating," "measuring," "performing," and the like refer to actions or processes of a particular 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 is capable of manipulating or transforming signals that are commonly represented as physical electronic, electrical, or magnetic quantities in the memory, registers, or other information storage, transmission, or display devices of the special purpose computer or similar special purpose electronic computing device.

[0081] The terms "and" and "or" as used herein may include various meanings that are also expected to depend at least in part on the context in which such terms are used. Typically, "or," when used to link an enumeration such as A, B, or C, is intended to mean A, B, and C, which are used herein in an inclusive sense, and A, B, or C, which are used herein in an exclusive sense. In addition, the term "one or more" as used herein may be used to represent any feature, structure, or characteristic in the singular, or may be used to represent any combination of features, structures, or characteristics. However, it should be noted that this is merely an illustrative example, and claimed subject matter is not limited to this example. Furthermore, the term "at least one of," when used to link an enumeration such as A, B, or C, may be interpreted to mean any combination of A, B, and / or C, such as A, AB, AA, AAB, AABBCCC, etc.

[0082] Although several embodiments have been described, various modifications, alternative configurations, and equivalents may be used without departing from the spirit of the present disclosure. For example, the above elements may simply be components of a larger system, and other rules may take precedence over or otherwise modify the application of the various embodiments. Also, some steps may be undertaken before, during, or after the above elements are considered. Thus, the above description does not limit the scope of the present disclosure. [Explanation of symbols]

[0083] 100 intersection 110 Crossing vehicles 120 Crossing Route 140 other vehicles 220 Crossing Route 230 Entrance Point 240 Exit point 250 Inside Lane 260 outside lane 300 Intersection 305 Crossing Vehicles 310 Crossing Route 315 Possible crossing routes 320 Another vehicle 325 Intersection 330 Crossing vehicles 335 Crossing Route 340 possible crossing routes 345 Another vehicle 350 Intersection 360 Crossing Vehicles 370 Crossing Route 400 Intersection 410 Crossing Vehicles 420 Crossing Route 430 Rail Lane 510 First Segment 520 Other Vehicles 610 Second Segment 710 Third Segment 900 Mobile Computer System 905 Bus 910 Processing Unit 915 Output Device 920 Digital Signal Processor (DSP) 930 Wireless Communication Interface 932 Wireless Communication Antenna 934 Wireless Signal 940 Sensors 960 Memory 970 Input Devices 980 GNSS Receiver 982 Antenna 984 signal 1000 Fixed Computer Systems 1005 Bus 1010 Processing unit 1015 Input Devices 1020 output device 1025 Non-transient storage devices 1030 Communication Subsystem 1033 Wireless communication interface 1035 Working Memory 1040 Operating Systems 1045 Applications

Claims

1. 1. A method of communicating information for vehicular traversal through a traffic intersection, comprising: obtaining information regarding the geometry of the intersection; A proposed route for the vehicle through the intersection from a predetermined entry point of one or more entry points of the intersection to a predetermined exit point of one or more exit points of the intersection. one or more characteristics of the vehicle; the geometric shape of the intersection; the one or more entry points; and said one or more exit points determining based at least in part on wirelessly transmitting a message indicative of the proposed route, the message including entrance and exit obstruction information indicating which entrance points of the one or more entrance points and which exit points of the one or more exit points are obstructed by the vehicle during a time period that the vehicle traverses through the intersection on the proposed route; A method comprising:

2. The message includes information indicating one or more segments of the proposed route, and for each segment, the message includes: the arrival time of the vehicle at each of the segments; and the departure time of said vehicle from each of said segments; 13. The method of claim 1, further comprising: wherein the entrance and exit obstruction information indicates, for each segment, which entrance points of the one or more entrance points and which exit points of the one or more exit points are obstructed by the vehicle between the arrival time of the vehicle at the respective segment and the departure time of the vehicle from the respective segment.

3. The method of claim 2 , wherein the one or more segments comprise a plurality of segments, and two segments of the plurality of segments overlap.

4. for each of the one or more segments, determining a geometric shape of the respective segment; The geometric shape for each of the one or more segments is: one or more static characteristics of the vehicle; one or more dynamic characteristics of the vehicle; the geometric shape of the intersection; one or more temporal characteristics of said intersection; the predetermined entry point of the one or more entry points; or the predetermined exit point of the one or more exit points; or Any combination of them The method of claim 2 , based at least in part on

5. the determining of the proposed route and the wireless transmission of the message indicative of the proposed route are performed by a component onboard the vehicle; or the determination of the proposed route and the wireless transmission of the message indicating the proposed route are performed by a roadside unit (RSU) component. The method of claim 1.

6. said determining said proposed route looking up a predetermined route in a database based on the geometry of the intersection, the one or more entry points, and the one or more exit points; or calculating the proposed route based on the one or more entry points and the one or more exit points. The method of claim 1 , comprising:

7. sending the message indicating the proposed route in response to a triggering event, the triggering event comprising: determining that the vehicle is within a threshold distance of the intersection; determining that the vehicle will arrive within a threshold distance of the intersection within a threshold amount of time; Or both The method of claim 1 , comprising:

8. 2. The method of claim 1, wherein the message indicating the proposed route comprises a Society of Automotive Engineers (SAE) message or an application layer message defined by the European Telecommunications Standards Institute Intelligent Transport Systems (ETSI-ITS).

9. 1. A device for communicating information for vehicular crossing through a traffic intersection, comprising: A wireless communication interface; Memory, one or more processing units communicatively coupled to the memory and to the wireless communication interface, obtaining information regarding the geometry of the intersection; a proposed route for the vehicle through the intersection from a predetermined entry point of one or more entry points of the intersection to a predetermined exit point of one or more exit points of the intersection; one or more characteristics of the vehicle; the geometric shape of the intersection; the one or more entry points; and said one or more exit points Based at least in part on wirelessly transmitting a message indicative of the proposed route over the wireless communication interface. one or more processing units configured to A device comprising:

10. The one or more characteristics of the vehicle include: Vehicle size, Vehicle type, Vehicle model, Whether the vehicle is towing a trailer or towed cargo; Safe stopping distance, Turning radius, Acceleration, or Deceleration, or Any combination of them The method according to claim 1 or the device according to claim 9, comprising:

11. the one or more processing units: information indicative of one or more segments of the proposed route; and For each segment, the arrival time of the vehicle at each of the segments; and the departure time of said vehicle from each of said segments; in the message The method further comprises: the one or more processing units are further configured to include, in the entry and exit obstruction information, per-segment information indicating which entry points of the one or more entry points and which exit points of the one or more exit points are obstructed by the vehicle between the arrival time of the vehicle at the respective segment and the departure time of the vehicle from the respective segment.

10. The device of claim 9.

12. the one or more processing units are further configured to determine, for each of the one or more segments, a geometric shape of the respective segment. The one or more processing units calculate the geometric shape for each of the one or more segments by: one or more static characteristics of the vehicle; one or more dynamic characteristics of the vehicle; the geometric shape of the intersection; one or more temporal characteristics of said intersection; the predetermined entry point of the one or more entry points; or the predetermined exit point of the one or more exit points; or Any combination of them configured to determine based at least in part on The device of claim 11.

13. a mobile computer system mounted on said vehicle; or Equipped with Roadside Unit (RSU), 10. The device of claim 9.

14. To determine the proposed route, the one or more processing units: looking up a predetermined route in a database based on the one or more characteristics of the vehicle, the geometry of the intersection, the one or more entry points, and the one or more exit points; or Calculating the proposed route based on the one or more characteristics of the vehicle, the geometry of the intersection, the one or more entry points, and the one or more exit points. or the one or more processing units: determining that the vehicle is within a threshold distance of the intersection; determining that the vehicle will arrive within a threshold distance of the intersection within a threshold amount of time; Or both configured to detect a triggering event comprising: The one or more processing units transmit the message indicating the proposed path in response to detecting the triggering event. It is configured as follows:

10. The device of claim 9.

15. 9. A non-transitory computer readable storage medium having instructions stored thereon for communicating information for the traversal of a vehicle through a traffic intersection, the instructions, when executed by one or more processing units, causing the one or more processing units to perform the method of any one of claims 1 to 8.

Citation Information

Patent Citations

  • Remote control system of intersection

    JP1992302400A

  • Assisting vehicle drivers in roundabouts

    JP2018536943A

  • Vehicle control method

    JP2019185772A

  • Determining driver intention at traffic intersections for automotive crash avoidance

    US10479373B2

  • Efficient intersection autonomous driving protocol

    US20130304279A1