Patent Publication Number: US-2022237583-A1

Title: Smart toll application determining for various toll applications using v2x communications

Description:
TECHNICAL FIELD 
     Aspects of the present disclosure generally relate to smart toll application determining for various toll applications using vehicle-to-everything (V2X) communications. 
     BACKGROUND 
     V2X Tolling may refer to electronic fee collection (EFC) toll charging supported by electronic equipment on-board of a vehicle configured for V2X communication. These V2X communications may include the exchange of information between various infrastructure elements. 
     SUMMARY 
     In one or more illustrative examples, a vehicle for smart tolling is provided. The vehicle includes a telematics control unit configured to provide vehicle-to-everything (V2X) communication and a processor. The processor is programmed to receive a toll advertisement message (TAM) broadcast from a roadside unit (RSU) via V2X communication, the TAM indicating geographic locations of lanes of a roadway for which tolls are due and cost information for traversing the lanes of the roadway. The processor is further programmed to determine a heading of the vehicle in relation to a TAM reference point indicating a geographic location of a toll gantry, and identify a toll zone boundary region for the vehicle by filtering the geographic locations of the lanes in the TAM to include only those lanes in a travel direction consistent with the heading. The processor is further programmed to utilize a lane straddling algorithm to identify, for each of the lanes in the travel direction, a respective percentage within each lane that the vehicle is traveling, and send a tolling usage message (TUM) via the V2X communication, the TUM indicating, to the RSU, the percentage lane usage of the vehicle. 
     In one or more illustrative examples, a method for smart tolling is provided. A toll advertisement message (TAM) broadcast from a roadside unit (RSU) is received by a vehicle via V2X communication, the TAM indicating geographic locations of lanes of a roadway for which tolls are due and cost information for traversing the lanes of the roadway. A heading of the vehicle is determined in relation to a TAM reference point indicating a geographic location of a toll gantry. A toll zone boundary region for the vehicle is identified by filtering the geographic locations of the lanes in the TAM to include only those lanes in a travel direction consistent with the heading. A lane straddling algorithm is utilized to identify, for each of the lanes in the travel direction, a respective percentage within each lane that the vehicle is traveling. A tolling usage message (TUM) is sent via the V2X communication, the TUM indicating, to the RSU, the percentage lane usage of the vehicle. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG. 1  illustrates an example system for the performance of V2X tolling transactions; 
         FIG. 2  illustrates aspects of a smart toll application that is executed by the vehicle; 
         FIG. 3  illustrates an example of a toll road geometry; 
         FIG. 4  illustrates an example of different road topologies; 
         FIGS. 5A, 5B, and 5C  collectively illustrate a data flow for performance of V2X tolling transactions; 
         FIG. 6  illustrates an example of a vehicle entering into proximity of the gantry; 
         FIG. 7  illustrates an example of determining toll-zone boundary offsets for a lane of the vehicle; 
         FIG. 8  illustrates an example of continued travel of the vehicle into the virtual toll-zone boundary in view of the lane node offsets and the virtual toll-zone boundary offsets. 
         FIG. 9  illustrates an example vehicle approach towards the toll trigger line; 
         FIG. 10  illustrates an example virtual trigger zone for the broadcasting of a toll usage message by the vehicle; 
         FIG. 11  illustrates an alternate example virtual trigger zone for the broadcasting of a toll usage message by the vehicle; 
         FIG. 12  illustrates an example data flow for determination of vehicle lane straddling; 
         FIG. 13  illustrates an example of a vehicle straddling two lanes; 
         FIG. 14  illustrates an example of various measurements for the determination of the vehicle straddling; 
         FIG. 15  illustrates an example data flow for determination of the virtual toll-zone boundary offsets; 
         FIG. 16  illustrates an example of determination of vehicle heading angle with respect to the travel direction of the vehicle; 
         FIG. 17  illustrates an example of the vehicle bounding box in view of the toll zone; and 
         FIG. 18  illustrates an example of a computing device for use in the performance of V2X tolling transactions. 
     
    
    
     DETAILED DESCRIPTION 
     Embodiments of the present disclosure are described herein. It is to be understood, however, that the disclosed embodiments are merely examples and other embodiments can take various and alternative forms. The figures are not necessarily to scale; some features could be exaggerated or minimized to show details of particular components. Therefore, specific structural and functional details disclosed herein are not to be interpreted as limiting, but merely as a representative basis for teaching one skilled in the art to variously employ the embodiments. As those of ordinary skill in the art will understand, various features illustrated and described with reference to any one of the figures can be combined with features illustrated in one or more other figures to produce embodiments that are not explicitly illustrated or described. The combinations of features illustrated provide representative embodiments for typical applications. Various combinations and modifications of the features consistent with the teachings of this disclosure, however, could be desired for particular applications. 
     Many electronic tolling systems using radio frequency identifier (RFID) and gantry-based technology platforms. Due to limitations in the data that may be transferred in current systems, there may be situations in which existing systems cannot properly detect and charge a passing vehicle due to conditions such as an obstructed license plate, an attached trailer, a vehicle straddling lanes, etc. For example, positioning of cameras on the gantry can limit the cameras from making more intelligent decisions. These decisions may include, as some examples: (i) proper lane tracking/identification by the vehicle; (ii) range of communication for vehicle maneuvering; (iii) identification of complex toll road geometries and topologies; (iv) precise determination of the vehicle within the lane; (v) communication of a toll usage message for the vehicle including reliably to the toll gantry system and precisely to the toll gantry system; (vi) determination of lane straddling of a vehicle for tolling (for example, open toll roads etc.) scenarios; and (vii) conveying information to the vehicle HMI regarding the toll-information being charged. 
     Moreover, existing systems may be incapable of providing rich data to support in-vehicle technologies to provide for an improved user experience. These in-vehicle technologies may include (i) real time information/notifications/alerts about the toll-usage-rates/toll-charged-rates in comfortable advance to the vehicle-customer approaching/exiting towards the toll zone; (ii) in-vehicle human-machine interface (HMI) information to the vehicle customer; and (iii) sharing and/or broadcasting vehicle usage information for the toll-road to toll authority agencies for smart, easy, and secure transactions. 
       FIG. 1  illustrates an example system  100  for the performance of V2X tolling transactions. As shown, the system  100  includes a wireless-enabled vehicle  102  configured to travel along a roadway  110 . The vehicle  102  includes a telematics control unit (TCU)  104  and an HMI  114 . The system  100  also includes a toll gantry  112  or other toll installation that includes a road-side unit (RSU)  108 . The RSU  108  communicates with a toll charger  116  over a secure channel (such as a wired connection), which in turn communicates with a toll pay center  118 . The toll pay center  118  also communicates with a toll agency hub  120  and a customer account system  122 . Using the TCU  104 , the vehicle  102  communicates with the RSU  108  over a broadcast peer-to-peer protocol (such as PC5), and with a communications network  106  over a network protocol, which allows the vehicle  102  to communicate with the customer account system  122 , for example. It should be noted that the system  100  shown in  FIG. 1  is merely an example, and systems having more, fewer, and different arrangements of elements may be used. For instance, one or more of the RSU  108 , toll charger  116 , toll pay center  118 , and toll agency hub  120  may be combined into a single device. Moreover, while only one vehicle  102  along one roadway  110  is shown, it is contemplated that systems  100  would include many vehicles  102  and roadways  110  to traverse. 
     The vehicles  102  may include various other types of passenger vehicles, such as sedans, crossover utility vehicles (CUVs), vans, sport utility vehicles (SUVs), trucks, recreational vehicles (RVs), scooters, or other mobile machines for transporting people or goods. In many cases, the vehicle  102  may be powered by an internal combustion engine. In such cases, the fuel source may be gasoline or diesel fuel. As another possibility, the vehicle  102  may be a hybrid electric vehicle (HEV) powered by both an internal combustion engine and one or more electric motors, such as a series hybrid electric vehicle (SHEV), a parallel hybrid electric vehicle (PHEV), or a parallel/series hybrid electric vehicle (PSHEV). As yet a further possibility, the vehicle  102  may be an electric vehicle (EV) powered by electric motors without an internal combustion engine. As the type and configuration of vehicles  102  may vary, the capabilities of the vehicles  102  may correspondingly vary. As some other possibilities, vehicles  102  may have different capabilities with respect to passenger capacity, towing ability and capacity, and storage volume. For title, inventory, and other purposes, the vehicle  102  may be associated with a unique identifier, such as a vehicle identification number (VIN). 
     The TCU  104  may be configured to provide telematics services to the vehicle  102 . These services may include, as some non-limiting possibilities, navigation, turn-by-turn directions, vehicle health reports, local business search, accident reporting, and hands-free calling. The TCU  104  may accordingly be configured to communicate over various protocols, such as with a communication network  106  over a network protocol (such as Uu). The TCU  104  may, additionally, be configured to communicate over a broadcast peer-to-peer protocol (such as PC5), to facilitate C-V2X communications with devices such as the RSU  108 . It should be noted that these protocols are merely examples, and different peer-to-peer and/or cellular technologies may be used. 
     The communications network  106  may provide communications services, such as packet-switched network services (e.g., Internet access, voice over Internet Protocol (VoIP) communication services), to devices connected to the communications network  106 . An example of a communications network  106  is a cellular telephone network. For instance, the TCU  104  may access the cellular network via connection to one or more cellular towers. To facilitate the communications over the communications network  106 , the TCU  104  may be associated with unique device identifiers (e.g., mobile device numbers (MDNs), Internet protocol (IP) addresses, etc.) to identify the communications of the TCU  104  on the communications network  106  as being associated with the vehicle  102 . 
     The RSU  108  may be a device with processing capabilities and networking capabilities, and may be designed to be placed in proximity of a roadway  110  for use in communicating with vehicles  102 . In an example, the RSU  108  may include hardware configured to communicate over the broadcast peer-to-peer protocol (such as PC5), to facilitate C-V2X communications with the vehicles  102 . The RSU  108  may also have wired or wireless backhaul capability to allow for communication with other elements of the communications network  106 , such as the toll charger  116 . 
     The toll gantry  112  may be framework installed across the roadway  110 . The toll gantry  112  may serve as a location to mount hardware to give the hardware a clear view of the roadway  110 . In an example, the RSU  108  may be mounted to the toll gantry  112 . It should be noted that, in other examples, the RSU  108  may be located along the ground adjacent to the roadway  110  and the toll gantry  112  may be omitted. 
     The HMI  114  may include various output devices configured to provide information to users, as well as input devices configured to receive information from users. Output devices may include, as some examples, display screens, touch screens, projectors, lights, speakers, buzzers, and haptic feedback sensors. Input devices may include, as some examples, touch screens, keyboards, buttons, knobs, and microphones, as some possibilities. 
     A global navigation satellite system (GNSS)  115  controller may be utilized by the vehicle  102  to provide autonomous geo-spatial positioning for the vehicle  102 . As some examples, the GNSS  115  controller may allow the vehicle  102  to determine its position using one or more satellite navigation systems, such as GPS, GLONASS, Galileo, Beidou and/or others. 
     The toll charger  116  is a networked computing device configured to perform operations in support of the functionality of the RSU  108 . In an example, the toll charger  116  may be in communication with the RSU  108  and may be programmed to operate as a gateway between the RSU  108  and the toll pay center  118 . The toll charger  116  may be responsible for managing operations between the broadcast nature of the RSU  108  operations and the remainder of the system  100 . These operations may include, for example, verification of messages received from vehicles  102  by the RSU  108 , certificate verification and identification, and communication with the toll pay center  118  to perform further operations over a secure line. In many examples, each RSU  108  may be supported by its own corresponding toll charger  116 . However, in other examples, a single toll charger  116  may be configured to handle multiple RSUs  108 , such as a set of RSUs  108  covering operation of the roadway  110 . 
     The toll pay center  118  is a networked computing device also configured to perform operations in support of the functionality of the system  100 . In an example, the toll pay center  118  may be programmed to perform operations in support of the payment aspects for use of the roadway  110  by the vehicle  102 . In some examples, the system  100  may include different toll pay centers  118 , where each toll pay center  118  is configured to handle payments for those vehicles  102  having accounts with the toll pay center  118 . As one possibility, different vehicle  102  manufacturers may each maintain their own toll pay center  118 . As another possibility, vehicles  102  may subscribe to the use of various third-party toll pay centers  118 . 
     The toll agency hub  120  is a networked computing device also configured to perform operations in support of the functionality of the system  100 . The toll agency hub  120  may be configured to perform operations such as providing cost information to the various toll pay centers  118  with respect to the costs for usage of the roadway  110 . For instance, the toll agency hub  120  may provide a toll schedule indicative of the costs of traversing the roadway  110 , including costs for usage of different lanes (e.g., express, carpool, regular, etc.), usage for different classes of vehicles  102  (e.g., passenger cars, semi-trucks, etc.), usage for different times of day, and usage for high traffic vs low traffic situations. The toll agency hub  120  may also be configured to perform payment reconciliation operations, reporting functions, and may also provide information regarding vehicles  102  that are observed on the roadway  110  that may not have paid (e.g., as identified according to wireless transmissions of basic safety messages (BSMs), pictures from cameras, etc.). 
     The customer account system  122  is a networked computing device also configured to perform operations in support of the functionality of the system  100 . Using the customer account system  122  a user may set up a payment account, be charged by the toll charger  116  for use of the roadway  110 , and request and receive toll receipts with respect to usage of the roadway  110 . Such payment transactions require the exchange of PI with toll authorities over the air. 
     Tolling operations may be performed using the elements of the system  100 . For instance, the toll agency hub  120  may send a toll rate schedule to the toll charger server  116 . This toll rate table may include information that may be used to allow a vehicle  102  to understand the charges that may be incurred to traverse the roadway  110 . In a simple example, the toll rate schedule may indicate that the cost to traverse the roadway  110  is a fixed amount. However, in many examples, the cost to traverse the roadway  110  may vary according to various factors. For instance, travel in a first lane may incur a first charge, while travel in another lane may incur a second, different, charge. In another example, the cost may vary based on the number of occupants of the vehicle  102 . In yet a further example, the cost may vary based on the type of vehicle  102  (e.g., a semitruck may incur a greater charge than a passenger car). In an even further example, costs may vary based on other factors, such as amount of traffic, time of day, day of week, and/or weather. 
     The toll charger server  116  may update rate details of toll advertisement message (TAM). In an example, the toll charger server  116  receives the toll rate schedule, identifies current rates, and updates rate information at the toll charger server  116 . This rate information may be cached at the toll charger server  116  and sent to the RSU  108 . The RSU  108  may broadcast the rate information as well as other information in a TAM message. This broadcast may be a periodic broadcast, such as a rebroadcast of the TAM every 100 milliseconds. 
     The TAM may include various information that may be useful for vehicles  102  in understanding usage of the roadway  110 . This may include fields such as: a timestamp indicative of the time at which the TAM was created or sent, toll types and toll amounts indicative of how the toll information is charged (e.g., based on the toll rate table), a layer type, a layer identifier, an identifier of the toll charger server  116 , and an identifier of the toll pay center  118 . The layer type may be a data element used to uniquely identify a type of information to be found in a layer of a geographic map fragment such as an intersection. The layer identifier may correspondingly be an identifier of map information. The identifier may be a globally-unique identifiers (GUID), to allow the toll pay centers  118  to be uniquely identified by the system  100 . 
     The TAM may also include map information indicative of the layout of the roadway  110 , such as an intersection geometry list and a road segment list. The road segment list include various properties of the roadway, including lane description, high occupancy status, and so on. This information may include, for instance, indications of the layout of the lanes of the roadway  110 , which may be used to allow vehicles  102  to identify when a tolled area is approached, as well as in which lane the vehicle  102  is traveling. Further aspects of map data and other details of message elements described herein are further defined in the J2735 standard Dedicated Short Range Communications (DSRC) Message Set Dictionary™, published by SAE International, the standard being incorporated herein by reference in its entirety. 
     The TAM  600  may also include other information such as a list of data parameters  620 . This may include, for instance, other information that may be relevant for tolling that does not fit into the other categories of information, such as special instructions for use of the toll roadway  110 . The TAM message  600  may also include a restrictions list  622 , which may include information regarding limits to access to the roadway  110 , such as weight limits, or restrictions against certain classes of vehicles  102  (e.g., no semitrucks allowed). 
     The TCU  104  of the vehicle  102  may receive the TAM broadcast by the RSU  108 . The vehicle  102  may logs entry into the roadway  110 . For instance, responsive to the geographic coordinates of the vehicle  102  matching one of the lanes of the roadway  110 , the TCU  104  may identify that the vehicle  102  is entering a specific lane of the roadway  110 . Knowing the lane of entry, the TCU  104  may then calculate the charge to be incurred by the vehicle  102 . The TCU  104  may also generate a toll usage message (TUM). 
     The TUM includes various information provided by vehicles  102  to RSUs  108  that indicates usage of the roadway  110  by the vehicle  102 . This information may include fields such as a message count that indicates a unique number of the TUM for the transaction. The message count may be used to help in identifying if any packet loss has occurred. The TUM may also include a unique random identifier that may be used as a temporary account identifier to track the transaction of messaging between the vehicle  102  and the broadcast message interface of the RSU  108 , while preserving relative anonymity of the vehicle  102 . 
     The TUM may also include information about the vehicle  102  entry to the toll area. For instance, the TUM may include a timestamp the time when the TUM was created, latitude, longitude, and elevation of the vehicle  102 , positional accuracy of the latitude, longitude, and elevation, speed of the vehicle  102 , and heading of the vehicle  102 . The TUM may also include other information, such as type of the vehicle  102 , an identifier of the toll charger server  116 , and an identifier of the toll pay center  118 . The identifiers may be GUIDs, to allow the toll charger servers  116  and toll pay centers  118  to be uniquely identified. The TUM may also include an intersection identifier of the intersection through which the vehicle  102  entered the roadway  110 , where the intersection identifier was received by the vehicle  102  in the TAM (e.g., via the intersection geometry list and/or road segment list). The TUM may also include a charge amount for the travel in the tolled area as determined by the vehicle  102  using the information in the TAM. Other information may also be included in the TUM, such as the distance traveled  830  by the vehicle  102 , a number of passengers in the vehicle  102 , and a license plate number or other identifier of the vehicle  102 . 
     The TCU  104  may update the HMI  114  to cause the HMI  114  to display a message indicating that the vehicle  102  entered the toll zone. The HMI  114  may further indicate that the vehicle  102  will be charged the amount indicated for the lane that the vehicle  102  is in. 
     The TCU  104  may send the TUM to the RSU  108 . In one example, the TUM may be encoded with a key and/or signed using a certificate, and the RSU  108  may utilize a key or other information to decrypt and/or confirm the sender of the TUM as being the TCU  104 . The RSU  108  may forward the TUM to the toll charger server  116 . The toll charger server  116  may forwards the TUM to the toll pay center  118  corresponding to the vehicle  102 . The toll pay center  118  may verify the vehicle  102  account with the customer account system  122  and complete the transaction. The pay center  118  may accordingly generates a toll receipt message (TRM) to be returned to the vehicle  102 . 
     In some examples, the vehicle  102  broadcasting the TUM may create an blockchain record of the TUM enforced as a smart contract. The RSU  108  may operate as a transaction database from the TUM information broadcast by the vehicle  102  through exchange of the smart contract. A transaction database at the RSU  108  may update a distributed block chain ledger of received TUMs for tolling enforcement at the RSU  108  and gantry  112 . 
     The TRM may include various information determined by the toll pay center  118  in support of completion of the toll transaction performed with the vehicle  102 . This information may include a message count (to help in identifying if any packet loss has occurred), the account identifier from the TUM, the timestamp the time when the TUM was created, an identifier of the toll charger server  116 , and an identifier of the toll pay center  118  (e.g., a GUID). The TRM may also include an intersection identifier of the intersection through which the vehicle  102  entered the roadway  110  (e.g., as indicated in the TUM that was processed by the toll pay center  118 ), a lane identifier of which lane through which the vehicle  102  entered the roadway  110  (e.g., as indicated in the TUM that was processed by the toll pay center  118 ), an intersection identifier of the intersection through which the vehicle  102  exited the roadway  110 , and a lane identifier of which lane through which the vehicle  102  exited the roadway  110 . The TRM may also include the vehicle type and the amount charged for access to the roadway  110 . 
     The toll pay center  118  may forward the TRM to the toll charger server  116 . In turn, the toll charger server  116  may forward the TRM back to the RSU  108 . The RSU  108  may broadcast the TRM, which may be received by the TCU  104  of the vehicle  102 . The TCU  104  may update the HMI  114  to display a message indicating completion of the process and the final charged amount. 
       FIG. 2  illustrates aspects of a smart toll application (STA)  202  that is executed by the vehicle  102 . The smart toll application  202  may be programmed to allow the vehicle  102  to perform various smart tolling operations discussed in detail herein. In an example, the smart toll application  202  may be executed by one or more processors of the TCU  104 . 
     The smart toll application  202  may receive various elements of data as input. In an example, these inputs may include TAMs  204  (as mentioned above), location information from the GNSS  115  controller, vehicle bus data  206  from a vehicle controller area network (CAN) or other vehicle  102  bus, vehicle assistance  208  information, in-built maps  210  to aid in location of the vehicle  102  along the roadway  110 , and TRMs  212  (also as mentioned above). 
     The smart toll application  202  may provide various outputs as well. In an example, these outputs may include HMI feedback  214  provided to the HMI  114  for use by occupants of the vehicle  102 , as well as TUMs  216  for use in charging the vehicle  102  via remote aspects of the tolling system  100  discussed above. 
     To perform the processing of the inputs into the outputs, the smart toll application  202  may include various components. These may include a tolling data aggregator  218  to process the TAMs  204  and TRMs  212 , an algorithm classifier  220 , a toll region determiner  222  to determine tolling ranges along the roadway  110 , a toll lane matcher  224  to match the vehicle  102  to the tolling ranges, a lane straddle algorithm  226  to determine whether the vehicle  102  is straddling across lanes, a position confidence  228  component to handle GNSS offsets sand other confidence factors, a position estimator  230  to estimate the vehicle  102  position, a path estimator  232  to estimate the vehicle  102  path using the vehicle  102  position, an algorithm overlay  234  to aid in providing the HMI feedback  214 , and an algorithm decision  236  component to provide the TUMs  216  and other outputs. 
       FIG. 3  illustrates an example  300  of a toll road geometry. As shown, a gantry  112  extends across lanes of a roadway  110 . The lanes of the roadway  110  include, for example, in a first travel direction, a shoulder, a first lane, a second lane, a third lane, and a shoulder. The illustrated roadway  110  further includes a center median, and lanes in a second travel direction, namely, a fourth lane, a fifth lane, a sixth lane, and a shoulder. It should be noted that the particular roadway layout is merely an example. An RSU  108  is in operation in control of the gantry  112 . 
     Lane node offsets  302  are also illustrated in the roadway  110 . These lane node offsets  302  indicate geographic locations along the roadway with respect to a reference point  304  indicating the geographic location of the gantry  112 . Which lane node offsets  302  to use may depend on the direction of travel of the vehicle  102 . For example, the vehicle  102 A is traveling in the first travel direction, and therefore may reference its location with respect to the lane node offsets  302  for the lanes in that travel direction (e.g., lanes one through three). These lane node offsets  302  may make up the toll advertisement zone  308 A for the first travel direction. The final lane node offsets  302  for each lane may collectively define toll trigger lines  306  at which the vehicle  102  may be configured to pay the toll. As the vehicle  102 B is traveling in the second travel direction, it therefore may reference its location with respect to the lane node offsets  302  for the lanes in that second travel direction (e.g., lanes four through six). These lane node offsets  302  may make up the toll advertisement zone  308 B for the second travel direction. 
       FIG. 4  illustrates an example  400  of different road topologies. A straight road topology is shown at (A), a curved road topology is shown at (B), and a polygon road topology is shown at (C). The straight and curved road topologies may be represented as a series of line node offsets  302  alone the travel path. The polygon road topology may be represented as a set of line node offsets  302  bounding the travel path. Regardless of how the road topology is represented, the information for the offsets may be broadcast by the RSU  108  in the TAM  204 . 
       FIGS. 5A, 5B, and 5C  collectively illustrate a data flow  500  for performance of V2X tolling transactions. The data flow  500  begins with the vehicle  102  entering into proximity of the gantry  112  and receiving the TAM  204  from the RSU  108 . An illustration of such a vehicle  102  is shown in  FIG. 6 . With continuing reference to  FIG. 5A , responsive to receipt of the TAM  204 , the vehicle  102  maintains the TAM  204  for further reference. 
     The vehicle  102  also receives position data from the GNSS  115  controller to identify the position of the vehicle  102 , as well as bus data from the vehicle bus  206  to determine vehicle movement direction and/or other vehicle  102  travel characteristics. These inputs are received to the smart toll algorithm  202 . 
     The vehicle  102  may take these inputs including the vehicle positioning data and starts converting the position to common xy-axis plane coordinates from the geodetic coordinates of the data. 
     The vehicle  102  may alert the driver about a toll zone ahead using the HMI  114 . This may be provided in sufficient time based on expected time of arrival (e.g., five minutes ahead, one minute ahead, etc.) or distance ahead (e.g., 1000 feet ahead, 500 feet ahead, etc.). The alert may be provided based on the TAM geodetic coordinates with vehicle&#39;s geodetic coordinates, direction-heading, speed, etc. 
     In addition to the coordinate conversion to a common xy-axis plane of the vehicle  102 , the vehicle  102  may calculate virtual toll-zone boundary offsets of the toll lanes along with the TAM lane node offsets and the TAM reference point. This may be done in view of the vehicle  102  heading, to only address points in lanes having the same travel direction as the vehicle  102  and filter out lanes in directions other than the direction of vehicle  102  travel (e.g., the opposite direction lanes of a highway). For instance, this determination of vehicle  102  direction may account for factors such as side slip angle. 
     As shown in the example  700  of  FIG. 7 , in addition to determining the virtual toll-zone boundary offsets  702  of the lane of the vehicle  102  based on data in the TAM  204 , a virtual toll-zone boundary  704  is created. The virtual toll-zone boundary  704  can be of various shapes for each of the n toll-lanes. This determination may be performed in view of the various types of road geometries shown in  FIG. 3 . 
     With continuing reference to  FIG. 5A , the algorithm utilizes the vehicle  102  geodetic xy-axis conversions in view of the virtual toll-zone boundary  704  to compute whether the vehicle  102  is within which of the toll zone lanes of the TAM  204  lanes. 
     In addition to the vehicle  102  determination of in which lane(s) the vehicle  102  is located within the respective virtual toll-zone boundary  704 , the vehicle  102  computes where the vehicle  102  is located within the xy-axis plane coordinates according to the GNSS positioning offset of the vehicle  102  GNSS antenna and the dimensions of the vehicle  102 .  FIG. 8  illustrates an example  800  of continued travel of the vehicle  102  into the virtual toll-zone boundary  704  in view of the lane node offsets  302  and the virtual toll-zone boundary offsets  702 . Further aspects of the determination of the virtual toll-zone boundary offsets  702  are discussed with respect to  FIG. 15 . 
     Referring more specifically to  FIG. 5B , based on the vehicle  102  behavior within the lane, the lane of travel of the vehicle  102  may be highlighted on the HMI  114 . For example, this may be provided as an overlay on the HMI  114  screen indicating details of the upcoming toll as identified from the information of the TAM  204  message. 
     In addition, the vehicle  102  continues to track the location of the vehicle  102  within the virtual toll-zone boundary  704  as the vehicle  102  approaches toe gantry  112 . This tracking may involve tracking factors from vehicle bus data such as time, distance, vehicle speed, etc. 
     If feedback is received from an occupant of the vehicle  102  (e.g., feedback through driving behavior or via the HMI  114 ) or from the vehicle  102  itself in autonomous situations, the vehicle  102  continues toward the toll trigger line  306  to continue the transaction. An example  900  of a vehicle  102  approach towards the toll trigger line  306  is shown in  FIG. 9 . 
     As shown in  FIGS. 10 and 11 , the vehicle  102  may, with respect to the toll trigger line  306  for the TUM  216 , create a virtual trigger zone  1002 . The toll may be charged responsive to the vehicle  102  being within the virtual trigger zone  1002 . As shown in the example  1000  of  FIG. 10 , the virtual trigger zone  1002  may be triangular. As shown in the example  1100  of  FIG. 11 , the virtual trigger zone  1002  may be rectangular. The specific shape of the virtual trigger zone  1002  may be of any polygonal shape and may depend on the shape of the TAM  204  toll zones. 
     With continuing reference to  FIG. 5B , the vehicle  102  may also estimate the path of the vehicle  102  within the virtual toll-zone boundary  704 , referencing the lane node offsets  302  where useful for estimation of the vehicle  102  behavior. The vehicle  102  may further publish the TUM  216  over the air to send to be received by the RSU  108  for communication to the toll charger  116 . 
     With reference to  FIG. 5C , the aforementioned procedure discussed with respect to  FIGS. 5A and 5B  may be simultaneously performed for all travel lanes in the toll advertisement zone  308  to account for all lanes of travel of the roadway  110 . Moreover, it should be noted that there may be instances in which the vehicle  102  straddles more than one lane of the roadway  110 . Thus, the vehicle  102  makes this determination as well. 
     As shown in  FIG. 5C , for lane straddling, the vehicle  102  utilizes a lane straddling algorithm  226  (discussed in further detail with respect in  FIG. 12 ) to account for vehicle  102  dimensions (e.g., length and width), vehicle GNSS positioning with antenna offsets, boundary offsets of the lanes etc. in determining whether straddling of lanes occurs. The vehicle  102  triggers a TUM  216  broadcast from the vehicle  102  to be provided to the RSU  108 . The TUM  216  may indicate the vehicle&#39;s respective percentage within each lane in the transmission. 
     The vehicle  102  may in some cases initiate another TUM  216  at predefined intervals until the vehicle  102  has not received a TRM  212  within various criteria such as within a predefined time period. After completion of receipt of the TUM  216  and transmission of the TRM  212  at the gantry  112 , the vehicle  102  may return to a standby state until receipt of another TAM  204  message awakes the STA  202 . 
       FIG. 12  illustrates an example data flow  1200  for determination of vehicle  102  lane straddling. As shown, the lane straddle algorithm  226  may be initialized as shown in  FIG. 5C  and may read GNSS antenna offsets. The GNSS antenna offsets may be specific to the vehicle  102  transceiver (and/or received from RSU  108  with respect to the location of the gantry  112 ) and used to allow the lane straddle algorithm  226  to better locate the vehicle  102  with respect to the gantry  112  reference point  304 . 
     The lane straddle algorithm  226  may further receive GNSS data indicative of the location of the vehicle  102 . Using this location, the generated virtual toll-zone boundaries  704 , and the lane width factors, the vehicle  102  may generate vehicle  102  left and right boundaries using the vehicle position and the vehicle  102  width to generate a virtual vehicle bounding box. This may include determining vehicle straddling virtual boundaries for the left side of the vehicle  102  and vehicle straddling virtual boundaries for the right side of the vehicle  102 . These vehicle boundaries may be cross checked with the lane boundaries to determine whether lane straddling is occurring. The result of this determination may include computation of a percentage output that the vehicle  102  is in each lane of the roadway  110 . This output may be provided to the STA  202 , e.g., for inclusion in the TUM  216 . 
       FIG. 13  illustrates an example  1300  of a vehicle  102  straddling two lanes. As shown, the vehicle  102  is straddling lanes one and two. In such an example, the data flow  1200  may determine that the vehicle  102  is 50% in lane1 and 50% in lane2. 
       FIG. 14  illustrates an example  1400  of various measurements for the determination of the vehicle  102  straddling. As shown, the GNSS data locates the vehicle  102  at the GNSS location  1402  in accordance with GNSS offsets calibrated specific to the transceiver of the vehicle  102 . Moreover, the vehicle  102  width is known. The vehicle width divided by two is then used to determine the vehicle left and right margins. These can then be compared against the lane margins. Similar determination may be done using a known vehicle  102  length. 
       FIG. 15  illustrates an example data flow  1500  for determination of the virtual toll-zone boundary offsets  702 . As shown, the virtual toll zone boundary algorithm  1502  may be initialized as shown in  FIG. 5A  and may read GNSS antenna offsets. The virtual toll zone boundary algorithm  1502  may further receive location data from the GNSS  115  controller and bus data, each as mentioned above. The virtual toll zone boundary algorithm  1502  may also access data from the TAM  204 . 
     Using the information, the virtual toll zone boundary algorithm  1502  identifies the heading of the vehicle  102 . To perform the virtual toll-zone boundary offsets calculation, information with respect to the vehicle heading is received via the bus data. The heading may be computed in relative angle coordinates to North (or another reference angle) in the same xy-coordinate system used with respect to the reference point  304  of the toll gantry  112 .  FIG. 16  illustrates an example  1600  of determination of vehicle  102  heading angle with respect to the travel direction of the vehicle  102 . 
     Based on the heading, the virtual toll zone boundary algorithm  1502  computes the virtual toll-zone boundary offsets  702 . These virtual toll-zone boundary offsets  702  are provided by the virtual toll zone boundary algorithm  1502  to the STA  202 .  FIG. 17  illustrates an example  1700  of the vehicle  102  bounding box in view of the toll zone. 
     Variations on the described systems and methods are possible. In an example, for instances when only a portion of the vehicles  102  have V2X connectivity, those vehicles  102  that do have connectivity could perform the sending of TUM messages for those vehicles  102  that lack connectivity. In another example, vehicles  102  that have V2X connectivity may be unable to reliably communicate with the RSU  108  for various reasons, such as data congestion, atmospheric conditions, line-of-sight obstructions, etc. In such instances, vehicles  102  with good connectivity to the RSU  108  may operate as relays between the further vehicles  102 . 
     In yet a further example, if a platoon of vehicles  102  is performing tolling operations with an RSU  108 , then a platoon leader may be configured to perform the tolling messaging for the platoon of vehicles  102  as a whole. This may improve system efficiency and reduce network traffic with the RSU  108 . 
       FIG. 18  illustrates an example  1800  of a computing device  1802  for use in the performance of V2X tolling transactions. Referring to  FIG. 18 , and with reference to  FIGS. 1-17 , the TCU  104 , RSU  108 , toll charger  116 , toll pay center  118 , and customer account system  122  may be examples of such computing devices  1802 . As shown, the computing device  1802  may include a processor  1804  that is operatively connected to a storage  1806 , a network device  1808 , an output device  1810 , and an input device  1812 . It should be noted that this is merely an example, and computing devices  1802  with more, fewer, or different components may be used. 
     The processor  1804  may include one or more integrated circuits that implement the functionality of a central processing unit (CPU) and/or graphics processing unit (GPU). In some examples, the processors  1804  are a system on a chip (SoC) that integrates the functionality of the CPU and GPU. The SoC may optionally include other components such as, for example, the storage  1806  and the network device  1808  into a single integrated device. In other examples, the CPU and GPU are connected to each other via a peripheral connection device such as PCI express or another suitable peripheral data connection. In one example, the CPU is a commercially available central processing device that implements an instruction set such as one of the x86, ARM, Power, or MIPS instruction set families. 
     Regardless of the specifics, during operation the processor  1804  executes stored program instructions that are retrieved from the storage  1806 . The stored program instructions, accordingly, include software that controls the operation of the processors  1804  to perform the operations described herein. The storage  1806  may include both non-volatile memory and volatile memory devices. The non-volatile memory includes solid-state memories, such as NAND flash memory, magnetic and optical storage media, or any other suitable data storage device that retains data when the system is deactivated or loses electrical power. The volatile memory includes static and dynamic random-access memory (RAM) that stores program instructions and data during operation of the system  100 . 
     The GPU may include hardware and software for display of at least two-dimensional (2D) and optionally three-dimensional (3D) graphics to the output device  1810 . The output device  1810  may include a graphical or visual display device, such as an electronic display screen, projector, printer, or any other suitable device that reproduces a graphical display. As another example, the output device  1810  may include an audio device, such as a loudspeaker or headphone. As yet a further example, the output device  1810  may include a tactile device, such as a mechanically raisable device that may, in an example, be configured to display braille or another physical output that may be touched to provide information to a user. 
     The input device  1812  may include any of various devices that enable the computing device  1802  to receive control input from users. Examples of suitable input devices that receive human interface inputs may include keyboards, mice, trackballs, touchscreens, voice input devices, graphics tablets, and the like. 
     The network devices  1808  may each include any of various devices that enable the TCU  104 , RSU  108 , toll charger  116 , toll pay center  118 , toll agency hub  120 , and customer account system  122  to send and/or receive data from external devices over networks (such as the communications network  106 ). Examples of suitable network devices  1808  include an Ethernet interface, a Wi-Fi transceiver, a cellular transceiver, or a BLUETOOTH or BLUETOOTH Low Energy (BLE) transceiver, or other network adapter or peripheral interconnection device that receives data from another computer or external data storage device, which can be useful for receiving large sets of data in an efficient manner. 
     While exemplary embodiments are described above, it is not intended that these embodiments describe all possible forms encompassed by the claims. The words used in the specification are words of description rather than limitation, and it is understood that various changes can be made without departing from the spirit and scope of the disclosure. As previously described, the features of various embodiments can be combined to form further embodiments of the invention that may not be explicitly described or illustrated. While various embodiments could have been described as providing advantages or being preferred over other embodiments or prior art implementations with respect to one or more desired characteristics, those of ordinary skill in the art recognize that one or more features or characteristics can be compromised to achieve desired overall system attributes, which depend on the specific application and implementation. These attributes can include, but are not limited to cost, strength, durability, life cycle cost, marketability, appearance, packaging, size, serviceability, weight, manufacturability, ease of assembly, etc. As such, to the extent any embodiments are described as less desirable than other embodiments or prior art implementations with respect to one or more characteristics, these embodiments are not outside the scope of the disclosure and can be desirable for particular applications.