SYSTEM AND METHOD FOR ROUTING AND REORGANIZATION OF A VEHICLE PLATOON IN A SMART CITY
Systems and methods described herein are provided for determining a platoon configuration for a group of vehicles, determining a set of routes connecting two locations, determining for each route segment the platoon configurations supported and the availability of roadside units on the route segment, and selecting a route from the set of routes connecting the two locations. A route may be selected based on the availability of a roadside unit (RSU) to request an extended time period for a green light to enable a length of the platoon to traverse through an intersection prior to the time period ending. Systems and methods described herein may enable a reconfiguration of a platoon to meet a platoon size restriction for a segment of the selected route.
The present application is a non-provisional filing of, and claims benefit under 35 U.S.C. § 119(e) from, U.S. Provisional Patent Application Ser. No. 62/431,736, entitled “System and Method for Routing and Reorganization of a Vehicle Platoon in a Smart City,” filed Dec. 8, 2016, the entirety of which is incorporated herein by reference.
BACKGROUNDA vehicle platoon is a group of vehicles that travels in close proximity to one another. Platooning may be one of the first automated vehicle technologies, especially for automation of commercial heavy goods vehicles. However, the development of platooning has been mainly focused on the highway environment.
Platooning, sometimes referred to as road trains, is a concept in which multiple vehicles travel in a group with synchronized driving dynamics through a Vehicular Ad-Hoc Network (VANET). Vehicles driving in a platoon communicate constantly and synchronize with each other. By use of platooning, the distances between vehicles may be reduced, overall fuel consumption may be lowered, and the number of drivers needed may be reduced.
ETSI and ISO have study items for platoon organization. 3GPP is considering semi- and fully automated platooning use cases. Autonet 2030 is working on convoying across non-uniform vehicle types.
In the next 5-10 years, platooning may be operated in limited automated modes, with limited drivers available to control a more-than-one vehicle platoon if needed. With NHTSA Level 3 automation, a driver is expected to be available to take full control when needed within comfortable transition time (e.g., 10 seconds). Splitting a platoon may cause undesirable results and may need to be planned in advance. The number of drivers for the platoon may need to be determined in advance.
Some publications relate to platoons in an urban environment, and some of these references discuss how platoons may interact with traffic signals. A journal article with a simulation study argued that saturation flow rates and intersection capacity in urban areas may be doubled or tripled by platooning vehicles with no change in signal controls at the intersections. Jennie Lions, et al., Platoons of Connected Vehicles Can Double Throughput in Urban Roads, CORNELL UNIVERSITY LIBRARY (Nov. 3, 2015).
An IEEE paper discusses how a platoon of autonomous vehicles can change formations in order to keep human-driven vehicles that lack V2V communications from interfering with the platoon. Guo Chunzhao, et al., Self-Defensive Coordinated Maneuvering of an Intelligent Vehicle Platoon in Mixed Traffic, 2012 15TH INTERNATIONAL IEEE CONFERENCE ON INTELLIGENT TRANSPORTATION SYSTEMS (ITSC) (2012).
The COMPANION project developed a process that matches trucks with overlapping routes together to platoons and adapts their speed profiles to meet on a highway during a transport. Sönke Eilers, Sergej Saibel, and Samuel Wickström, Cooperative Dynamic Formation of Platoons for Safe and Energy-Optimized Goods Transportation, D3.2: Information Model for Platoon Services, COMPANION, page 17.
The AutoNet2030 project has studied formation control of multi-lane vehicular convoys in highways where networked intelligent vehicles may join or leave the formation dynamically. Ali Marjovi, et al., Distributed Graph-Based Convoy Control for Networked Intelligent Vehicles, 2015 IEEE INTELLIGENT VEHICLES SYMPOSIUM (IV) (2015). The AutoNet2030 project has also specified inter-vehicle communications for a convoy driving service that enables cooperative vehicles to make automated adjustments of speed, heading, and lane usage according to a decentralized mechanism. Laurens Hobert, ed., Specifications for the Enhancement to Existing LDM and Cooperative Communication Protocol Standards, AUTONET 2030 (Feb. 6, 2015).
A paper of A. Ferrara and C. Vecchio describes a study of the use of cruise control in urban areas where pedestrians or other vulnerable road users (VRUs) may be present. Increasing pedestrians' safety may be attained by providing a control system of platoon vehicles with a collision avoidance capability. A. Ferrara and C. Vecchio, Sliding Mode Control for Automatic Driving of a Platoon of Vehicles, VSS'06 INTERNATIONAL WORKSHOP ON VARIABLE STRUCTURE SYSTEMS (2006).
U.S. Patent Application 2014/0210645 relates to optimizing automobile traffic flow through an intersection by detecting and reducing platoon interference. One method determines a cluster in traffic information of a cycle of a traffic signal, determines that the cluster qualifies as an upstream platoon, calculates properties of the platoon, and generates an Enhanced Purdue Coordination Diagram (EPCD) for the cycle based on the calculated properties of the platoon. Another method calculates a traffic signal timing change to improve traffic flow through an intersection based on platoon properties corresponding to each cycle of the intersection's traffic signal.
PCT Patent Application WO20100103504 relates to coordinating traffic at an intersection by adjusting the speed of platoon vehicles a predetermined distance from an intersection based on the adjusted velocity and platoon vehicle length, where the platoon vehicle length goes through an affine transformation of translation and scaling when crossing the predetermined distance due to the velocity adjustment. Additionally, a method and system for coordination between intersections are provided.
U.S. Patent Application 2016/0019782 relates to a method for increasing road safety in vehicle platoons, including presenting to vehicles not part of the vehicle platoon, based on information determined by the vehicle platoon, information intended to increase road safety.
U.S. Patent Application 2008/0134955 relates to improving highway safety by use of indicators, such as flags, magnetic signs, projected images, illuminated signs, window decals, or beacons, that show the existence of a convoy of vehicles and the position of a vehicle in the convoy.
U.S. Pat. No. 8,352,111 relates to a platoon leader vehicle controlling a platoon of vehicles by monitoring the position of non-leader vehicles, determining distances to operate the non-leader vehicles based upon the respective actual positions, and selecting a respective commanded vehicle position including a respective global positioning coordinate for each of the plurality of vehicles based upon the determined distances.
PCT Patent Application WO2014139821 relates to controlling a semi-autonomous vehicle by aggregating data from various sources to position and orient the vehicle, assigning an autonomous driving value to different route segments, determining an optimal route by minimizing a distance between a start position and a destination position, maximizing the percent autonomous value assigned, and displaying the optimal route.
U.S. Patent Application 2016/0025505 relates to an apparatus for generating a global path for an autonomous vehicle, including a sensor module including one or more sensors installed in the vehicle, a traffic information receiver configured to receive traffic information through wireless communication, a path generator configured to generate one or more candidate paths based on the traffic information, a difficulty evaluator configured to evaluate a difficulty of driving in the one or more candidate paths in each section of the one or more candidate paths using recognition rates of the one or more sensors and the traffic information, and an autonomous driving path selector configured to finally select an autonomous driving path by evaluating the one or more candidate paths based on the evaluation of the difficulty of driving.
SUMMARYSystems and methods described herein include methods for minimizing platoon interruption and platoon splitting while traveling through a smart city. Systems and methods described herein also may determine a route plan, including platoon organization while traveling in smart city.
Platoon route planning may determine a suitable route for the platoon based on platoon characteristics. A platoon formation planning module may determine an optimal formation (e.g., where to use one or two lanes) for the platoon along the route by maximizing efficiency (e.g., intersection throughput) and minimizing impact to other road users.
Embodiments described herein improve the ability of a vehicle platoon or convoy to travel through a city by utilizing a smart city system to find an optimal route, formation, and other driving instructions for a platoon. Using methods and systems described herein, a smart city may minimize negative effects of platoons to other road users, for example, by taking into account types and numbers of vehicles in a platoon, length of a platoon, and availability (via V2I for one embodiment) of roadside units to support a platoon. Systems and methods described here may determine a platoon's ability to reorganize.
One embodiment of systems and methods described herein select a route for a group of vehicles, comprising: identifying a plurality of available platoon configurations for the group of vehicles; determining a plurality of route options from a first location to a second location, each route option comprising a plurality of segments; determining, for each of the plurality of segments of the plurality of route options, whether the respective segment supports at least one of the identified platoon configurations; selecting, from among the plurality of route options, a route for which each segment of the selected route has been determined to support at least one of the identified platoon configurations; and communicating the selected route to at least one vehicle in the group of vehicles.
One embodiment further comprises selecting, for each segment along the selected route, a corresponding platoon configuration that is supported by that segment; and communicating the selected platoon configurations to the at least one vehicle in the group of vehicles. One embodiment for selecting the route comprises eliminating route options from the plurality of route options that contain at least one segment that does not support at least one platoon configuration of a group of vehicles; calculating a route score for each of the plurality of route options not eliminated; and selecting the route from the plurality of route options wherein the route score of the selected route is above a threshold.
The entities, connections, arrangements, and the like that are depicted in—and described in connection with—the various figures are presented by way of example and not by way of limitation. As such, any and all statements or other indications as to what a particular figure “depicts,” what a particular element or entity in a particular figure “is” or “has,” and any and all similar statements—that may in isolation and out of context be read as absolute and therefore limiting—may only properly be read as being constructively preceded by a clause such as “In at least one embodiment, . . . .” In this specification, the term “platoon” is used to cover both vehicle platoons that use only a single lane and vehicle convoys that may use several lanes.
DETAILED DESCRIPTIONResearch shows that vehicle platoons of connected vehicles may double throughput in urban roads. Jennie Lioris, et al., Platoons of Connected Vehicles Can Double Throughput in Urban Roads, CORNELL UNIVERSITY LIBRARY (Nov. 3, 2015). The present disclosure relates to systems and methods for directing platoons or convoys in an urban environment.
Currently, navigation systems calculate a route by minimizing fuel consumption, travelling time, or CO2 emissions. Some navigation or routing methods for heavy goods vehicles or trucks may take into account vehicle weight or height limitations. There are also some predefined dedicated routes for dangerous goods transport in urban areas. Routes selected by these navigation or routing systems are not based on vehicle platoons.
Systems may generate a route of global path for an autonomous vehicle to maximize the fully automated or autonomous driving. However, these systems make decisions based only on a single vehicle and do not based on a platoon of vehicles or various vehicle types. Existing navigation systems are not designed for optimizing a route or formation of a vehicle platoon in an urban environment. Moreover, the routing based on static information (such as fixed routing of a dangerous goods transport through a city) may not be the most optimal one, and a smart city may provide various up-to-date data and services to support platoons. Platoons and convoys, which may utilize several lanes, may be used in urban an environment to make traffic more efficient. Smart cities may provide support and guide these platoons and convoys in optimized routes and formation. Splitting a platoon is undesirable and may need to be determined in advance. The number of drivers in a platoon used in a platoon may be calculated in advance. Systems and methods described herein provide ways to improve planning of a vehicle platoon route and to determine where to reorganize a platoon vehicle in a smart city.
Systems and methods described herein may include for some embodiments several advantages, such as a platoon may determine an optimal route and formation within a smart city. Before executing a plan, a platoon may determine where to reorganize (such as changing from a one-lane to a two-lane configuration) while diving through a city to maximize throughput in signalized intersections. Systems and methods described herein may interface with a smart city to minimize negative effects of a platoon on a city or other road users. Traffic safety and efficiency may be increased in embodiments where a smart city is able to dynamically control where, when, and what types of platoons traverse (or travel) through a city. Platoons may be routed based on a category (such as vehicle type, number of vehicles, and platoon length). For example, vehicle platoons (especially platoons containing heavy vehicles) may not be allowed in city areas if there are lots of pedestrians or other vulnerable road users (VRUs). Light city vehicle platoons with small numbers of vehicles may be used more widely. Also, investments in roadside units, which may be used to support platoons, may be maximized if platoons are routed through these intersections.
A route and platoon planning service (RPPS) 1008 running as a smart city cloud service may contain information storage 1020 and a route and platoon planning application 1022. Information storage 1020 may contain platoon profiles, a vehicle to infrastructure (V2I) RSU database, and traffic history data. Platoon profiles may include predefined categorizations of platoons. A V2I RSU database may contain current locations of roadside units 1012 capable of V2I communications with a platoon. Traffic history data may include history data about the impacts of platoons in a city area, such as how different size platoons affect intersection traffic.
A route and platoon planning application 1022 running on an RPPS 1008 may determine platoon routes in a smart city using some of the following modules: a route planning module 1032, a platoon formation planning module 1034, a platoon categorization and route limitation module 1036, and a communication module 1038 for interfacing with external APIs and external services 1010. A route planning module 1032 may determine a platoon route based on platoon category, restrictions on travel areas for platoons (for example, near schools), current traffic conditions in a city, event information, weather, time of day, and locations of V2I roadside units. A platoon formation planning module 1034 may determine optimal platoon formation (such as where to use one or two lanes) to maximize efficiency (for example, intersection throughput) and to minimize impact to other road users. A platoon categorization and route limitation module 1036 may classify a platoon using predefined categories according to platoon vehicle types, platoon length, and ability to organize a platoon in multiple lanes. This categorization may be used to determine which streets may be used by a platoon. A communication module 1038 may be used to interface with external services 1010, such as weather services 1040, map data services 1042, and traffic/event/roadwork information services 1044.
External services 1010 may include service-level modules 1004. These modules 1004 may include a weather service 1040, a map data service 1042, and traffic/event/roadwork information service 1044. A roadside unit (RSU) 1012 may be connected to an RPPS 1008 and execute a traffic and conditions module 1046. A traffic and conditions module 1046 may monitor traffic and conditions in the RSU location and may report to an RPPS 1008. A vehicle platoon 1006, a route & platoon planning service 1008, external services 1010, and RSUs 1012 may communicate with each other using a wide area communication network 1014, such a cellular system.
Determining routing may also minimize safety hazards by avoiding crossings or street sections with lots of pedestrians or other VRUs, such as schools or nurseries during day and areas with active road construction (or road work). A smart city may have areas where certain kinds of vehicle platoons are not allowed. A smart city platoon categorization and route limitation component takes these issues into account before calculating an actual route.
A platoon categorization may be determined according to the number of vehicles, length of the vehicles, gap between vehicles, and the formations in which a platoon may travel. The minimum platoon length supported for each formation may be calculated. For example, a platoon formation may be one lane (of eight vehicles), two lanes (of four vehicles each), or three lanes (two lanes of three vehicles plus one lane of two vehicles). For this example, the platoon may be reorganized to one or multiple lanes. The platoon may be driving toward a city area in a two-lane formation. The platoon length, for example, may be 55 meters for a one-lane configuration and 30 meters for a two-lane formation. A route determination process may determine which streets in a city allow the platoon.
Table 1 is an example table of platoon size segment limits for an example configuration. These limits may be set by a smart city. Table 1 is based on the street map shown in
For the example shown in
For this example, a routing service has determined two candidate routes through a city. Route 1 (536) starts at the circle with a “1” inside the circle 502 and continues to an exit of the city 506. Route 1 (536) includes reorganization of the platoon. Route 1's solid line indicates a route section where the platoon may use 2 lanes, and the dashed line indicates a route section where the platoon may use only one lane. The location to reorganize the platoon to a single lane 532 is indicated with a “narrow street” traffic sign and reorganization location to multiple lanes 534 is indicated with a “narrow street” upside-down. There are 4 roadside units (RSUs) 520, 522, 528, 530 on the route which communicate that there are no traffic incidents and that the RSUs may communicate other support messages for the platoon. For this example, route 1 (536) is the fastest route.
Route 2 (538) starts at the circle with a “2” inside the circle 504 and continues to an exit of the city 508. Route 2 (538) goes through a slow traffic area (location B), and route 2 (538) is not as fast as route 1 (536). Route 2 (538) may be driven without any reorganization of the platoon. For some embodiments, a platoon leader vehicle may choose which route to take. Route 2 (538) includes two RSUs 524, 526 on the route which communicate that there are no traffic incidents and that the RSUs may communicate other support messages for the platoon. Additionally, there is an RSU 518 not part of route 1 (536) or route 2 (538).
As part of the process of selecting and traversing (or traveling) a route, a smart city route and platoon planning service (RPPS) 604 updates 610 with the locations of RSUs 608 along the route. The RSUs 608 may be capable of sending messages to traffic lights to request longer green lights, for example. For some embodiments, RSUs 608 may be movable. A platoon requests a route and driving instructions from a smart city. A platoon category may be used to classify the platoon based on the number of vehicles, vehicle types, and length of the platoon. A Platoon Management Module 602 sends a Route Request 612 to an RPPS 604. For some embodiments, a Route Request 612 may include a platoon category, types of vehicles, automation level, and route time window. A set of candidate routes for the platoon may be calculated 614 based on a fastest route calculation using the street network available for the platoon. A Smart City's RPPS 604 may query 616 and receive 618 current platoon route restrictions (or limitations) from (external) a traffic management system 606 based on traffic, events, roadwork (construction), and weather data. For some embodiments, an RPPS 604 may send a traffic condition requests to RSUs 604 along a candidate route. An RSU 608 may respond with a status report that may include traffic condition information at an RSU location. Information may also include current traffic volumes, the number of pedestrians in the vicinity, other VRUs, the status of RSU support for platoons, and road alerts (e.g., a lane blocked). Based on the location of traffic lights (with and without RSU support) on the routes and, optionally, up-to-date information from RSUs, a route is selected 620 from a list of candidate routes. For some embodiments, several candidate routes may be communicated to a platoon leader vehicle to choose a route. For some embodiments, a selected route is communicated from a platoon management module 602 to an RPPS 604.
An RPPS 604 may send an RSU signal phase and timing (SPAT) Capabilities Query message 622 to an RSU. The RSU 608 may respond with RSU capabilities for the candidate route 624. The candidate route may include the driving direction through each intersection with an RSU (e.g., straight, turn right or left). An RSU SPAT capabilities reply message 624 from an RSU 608 may include RSU location, RSU status and capabilities, and candidate platoon formations. The RSU location field may include coordinates of an RSU. The RSU status and capabilities field may include current condition of an RSU (e.g., all systems running normal, or a list of systems not working properly), whether an RSU is able to support a platoon via V2I communications and an ability to communicate a priority request message to a traffic light for a longer green light. The candidate platoon formations field may include which formations (such as one- or two-lane) a platoon may use if traveling through an intersection in a planned driving direction.
For some embodiments, the RPPS 604 may determine 626 an optimal formation based on intersection layouts of the planned route, RSU information, and locations where platoon reorganization may be done in the route. For example, a platoon may reorganize (e.g., use 1 or 2 lanes) before each crossing in order to travel efficiently through a smart city and to adjust a platoon's configuration based on current traffic conditions. The RPPS 604 communicates 628 the route(s) and formation plan to the platoon module 602. For each route option (R ∈ r), a platoon formation along component route segments, a time window in which a formation is valid, and identification of associated RSUs may be sent 628 from an RPPS 604 to a platoon management module 602.
For some embodiments, the route(s) are chosen 630 by the platoon leader vehicle (which may occur via a platoon management module 602) and communicated 632 to an RPPS 604. An RPPS 604 sends a Platoon ETA Query message 634 to an RSU 608, which may send a Platoon ETA Response message 638. Platoon ETA Query and Response messages 634, 638 may include a platoon ID, a planned platoon formation (configuration) and estimated time of arrival for each RSU along the route(s). Platoon ETA Query and Response messages 634, 638 may include a platoon identification (ID), a planned platoon formation (configuration), and an estimated time of arrival at each RSU along a route. The RSU 608 may arrange scheduling for a platoon 636. An RSU 608 may determine traffic light timing for the platoon and may send a request to a traffic light for an extended green light, for example. Platoon Identification Assertion messages 640 may be sent to RSU along a route.
For an RSU locations and capabilities message 714 sent from an RSU 710 to a traffic management system 708 and forwarded 716 to an RPPS 706, RSU location fields may include latitude and longitude coordinates of an RSU. Such a message 714, 716 may also include platoon capabilities supported by an RSU.
An RPPS 706 determines 724 a set of candidate routes for the platoon. For some embodiments, this determination 724 is based on route restrictions queried 720 by an RPPS 706 and responded 722 by a traffic management system 708. For some embodiments, the RPPS 706 determines 724 which route to use from the set of candidate routes. For one embodiment, an RPPS 706 may determine 726 which platoon configurations to use. Also, the RPPS 706 may determine 728 which RSUs 710 support at least one platoon configuration. A selected route may be communicated 730 from an RPPS 706 to a platoon management module 704. For one embodiment, the selected route may be communicated 730 with a set of waypoints (e.g., intersections), along with a list of RSUs that may provide support. For some embodiments, several routes may be provided 732 optionally for a platoon (or platoon leader vehicle 702) to choose. A list of alerts related to the selected route may be communicated to the platform management module 704. An RPPS 706 may also communicate formation instructions for the platoon to drive and locations where a platoon may reorganize (if needed). Instructions may be communicated for each segment in the route, including information for the platoon, such as recommended speed, gap between vehicles, recommended platoon formation through intersections (one lane or multiple lanes).
For some embodiments, an RPPS 706 may send a request to a traffic management system or external service for a status report of traffic conditions. The request message may include RSU location, RSU status and capabilities, vehicle traffic volumes, the number of local pedestrians, the number of VRUs, and route alerts. The RSU location field may include the coordinates of an RSU. The RSS status and capabilities field may include the current condition of the RSU, RSU capabilities, and RSU platoon support. The current condition of the RSU may include values representing the state where all RSU systems are working or values corresponding to the systems not working properly. RSU capabilities may include detection of vehicle traffic, pedestrians, and VRUs. RSU platoon support may include V2I communications and the ability to communicate priority signal timing messages to traffic signals to request a longer green light. The vehicle traffic volumes field may include current traffic volumes at the RSU location. The number of pedestrians may include volume of pedestrian traffic near the RSU. The number of VRUs is the number of VRUs detected near the RSU. The alerts field in the number of detected alerts, such as whether a lane is blocked and the time such an alarm condition occurred. The alerts field may be codes using, for example, the event codes employed in the Traffic Message Channel (TMC) system or analogous codes.
For one embodiment, a Platoon Leader 702 may configure an RSU 734. A Platoon Management module 704 may send an RSU Configuration message 736 to a Traffic Management System 708, which is forwarded 738 to an RSU 710. Platoon Credentials may be sent 740 from a Platoon Management module 704 to an RSU 710.
Tables 2 and 3 are example tables for using vehicle category and level of automation in determining a platoon route. Platoon categorization may be performed based on the following example. A smart city may assign different values to vehicle categories for use in calculating a vehicle score. A smart city may use this method to limit the number of heavy vehicles in the city or a portion of the city. Table 2 lists an example vehicle category scoring table. For some embodiments, a smart city control system or device may change dynamically vehicle category scoring values.
Table 3 lists an example automation level scoring table. For some embodiments, scores may be calculated for each vehicle in the platoon and added together. Vehicle score and automation score may be added together to calculate a total platoon category score.
For example, vehicle category and automation scores may be calculated for a platoon with three passenger cars with an automation level of 3 and two buses with an automation level of 4. The vehicle score of 24 may be calculated as 3 vehicles times 4 points per vehicle plus 2 vehicles times 6 points per vehicle. The automation score of 13 may be calculated as vehicles times 3 points per vehicle plus 2 vehicles times 2 points per vehicle. Adding the vehicle category and automation scores together calculates a total category score of 37 for this example. For this example, the platoon may be reorganized as one or multiple lanes. In an example, a platoon is driving towards the city area in a two-lane formation. The platoon length is 55 meters in a one-lane formation and 30 meters in a two-lane formation.
Table 4 is a table of example maximum category scores for street segments. A platoon category score may be used to determine which streets would allow the platoon. In
A route calculation limits the number of candidate routes, which are available for the platoon in the city. The route selection may use crossings equipped with V2I roadside units (RSUs), which may support platoons. These RSUs may communicate priority signal timing and platoon priority requests to traffic lights. This system or method may be used to avoid splitting a platoon at a traffic light.
Table 5 is an example table of node scores that may be used to calculate a total platoon driving score for a route. If a platoon approaches a smart city, candidate routes may be determined and ranked based on a current feedback report from RSUs and the number of traffic lights with and without RSUs on each route. The values shown in the table for Table 5 may be used with the two example routes shown in
For some embodiments, the following method may be used to select a platoon route. Intersections with a right of way and without a traffic light have a ranking score of zero. For this example, nodes B, C, F, H, and P are in this category. Intersections without a right of way (such as no stop sign or no obligation to yield the right of way) and without a traffic light have a ranking score of −3. An intersection with traffic lights but without an RSU have a ranking score of −1. Node K is in this category. An intersection with traffic lights and with a right of way may have a ranking score set based on the latest status report from the RSU. If an RSU communicates a current condition of OK, the RSU has the ability to send signal timing to a traffic light as part of a platoon priority request, and the traffic is at a normal or minimal level, a ranking score of 2 may be used. If an RSU communicates a current condition of OK and the traffic is at a normal or minimal level, a ranking score of 0 is used; hence, an RSU in this situation lacks the ability to send priority requests to a traffic signal. If an RSU communicates a current condition of not OK, but the traffic is at a normal level, a ranking score of −1 is used. If vehicle traffic, the number of pedestrians, or the number of VRUs is high, a ranking score of −2 is used. If a traffic alert has been received regarding the intersection, a ranking score of −3 is used.
Ranking of each candidate route may be calculated for traversing (or traveling) through each node on a route. For example, some RSUs communicate good conditions and some RSUs lack the ability to send platoon priority signals to a traffic light. For the two routes shown in
For other embodiments, the lead platoon vehicle may calculate platoon routes and determine platoon formations using detailed map information. The lead vehicle may send a query message to a smart city system or device to determine current platoon limitations (such as roadwork or traffic conditions) and available RSUs. A platoon leader vehicle may send selected route and formation information and ETA estimates to each RSU along the selected route and to a smart city traffic management service.
For other embodiments, a platoon may indicate in a route request which vehicles may leave (or join) the platoon prior to reaching the route destination. For example, a route request may include additional information, such as the location a vehicle may depart from the platoon. For example, a route request may be divided into several sections, and for each section, the number (and type) of vehicles may be communicated. For this example, a route calculation process may determine a different recommended (or selected) route if the number of vehicles at the route destination is smaller than at a route's origin. Similarly, a route calculation process may determine a different recommended (or selected) route if the number of vehicles at the route destination is larger than at a route's origin.
For another embodiment, if the destination of the platoon is in an area where the platoon or type of platoon is not allowed, the platoon may use smart city routing to get near the destination and continue as separate vehicles after that point.
For another embodiment, a smart city system or device may communicate to the platoon a suggested platoon size, a maximum number of vehicles allowed for a platoon, or a platoon configuration restriction. A platoon may be split into two platoons, if available, before entering a city.
For another embodiment, a route may be selected based on the time of arrival of the platoon at a route's destination.
Use CasesIn an exemplary use case for at least one embodiment, in the late evening, a vehicle platoon approaches a city, and the operator of the leading vehicle notices that an RPP application has automatically started and is sending a route request to the smart city. After a few seconds, a recommended route appears on a human-machine interface (HMI) in the lead vehicle. The operator notices that the route goes through the center of the city and that there are multiple roadside units available to support the platoon through traffic lights. While traversing the route, no alerts are received by the leading vehicle. Also, no traffic jams and very few pedestrians are seen. A route plan includes a route section where platoon formation is one lane, and reorganization locations are communicated with other instructions for the platoon. The operator accepts this recommendation, and the RPP application transmits this data to a platoon management system. The platoon management system executes the instructions for the platoon. The operator continues to monitor the HMI for messages while the platoon traverses (or travels) efficiently through the city.
Network ArchitectureA wireless transmit/receive unit (WTRU) may be used as a platoon vehicle communications device in embodiments described herein. The network architecture shown in
As shown in
The communications systems 100 may also include a base station 114a and a base station 114b. Each of the base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as the core network 106/107/109, the Internet 110, and/or the networks 112. By way of example, the base stations 114a, 114b may be a base transceiver station (BTS), a Node-B, an eNode B, a Home Node B, a Home eNode B, a site controller, an access point (AP), a wireless router, and the like. While the base stations 114a, 114b are each depicted as a single element, the base stations 114a, 114b may include any number of interconnected base stations and/or network elements.
The base station 114a may be part of the RAN 103/104/105, which may also include other base stations and/or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, and the like. The base station 114a and/or the base station 114b may be configured to transmit and/or receive wireless signals within a particular geographic region, which may be referred to as a cell (not shown). The cell may further be divided into sectors. For example, the cell associated with the base station 114a may be divided into three sectors. Thus, in one embodiment, the base station 114a may include three transceivers, one for each sector of the cell. In another embodiment, the base station 114a may employ multiple-input multiple output (MIMO) technology and, therefore, may utilize multiple transceivers for each sector of the cell.
The base stations 114a, 114b may communicate with one or more of the WTRUs 102a, 102b, 102c, 102d over an air interface 116, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, and the like). The air interface 116 may be established using any suitable radio access technology (RAT).
More specifically, as noted above, the communications system 100 may be a multiple access system and may employ one or more channel-access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. For example, the base station 114a in the RAN 103/104/105 and the WTRUs 102a, 102b, 102c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the air interface 116 using wideband CDMA (WCDMA). WCDMA may include communication protocols such as High-Speed Packet Access (HSPA) and/or Evolved HSPA (HSPA+). HSPA may include High-Speed Downlink Packet Access (HSDPA) and/or High-Speed Uplink Packet Access (HSUPA).
In another embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may establish the air interface 116 using Long Term Evolution (LTE) and/or LTE-Advanced (LTE-A).
In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement radio technologies such as IEEE 802.16 (Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), and the like.
The base station 114b in
The RAN 103/104/105 may be in communication with the core network 106/107/109, which may be any type of network configured to provide voice, data, applications, and/or voice over internet protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. As examples, the core network 106/107/109 may provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, video distribution, and the like, and/or perform high-level security functions, such as user authentication. Although not shown in
The core network 106/107/109 may also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and/or other networks 112. The PSTN 108 may include circuit-switched telephone networks that provide plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols, such as the transmission control protocol (TCP), user datagram protocol (UDP) and IP in the TCP/IP Internet protocol suite. The networks 112 may include wired and/or wireless communications networks owned and/or operated by other service providers. For example, the networks 112 may include another core network connected to one or more RANs, which may employ the same RAT as the RAN 103/104/105 or a different RAT.
Some or all of the WTRUs 102a, 102b, 102c, 102d in the communications system 100 may include multi-mode capabilities, and the WTRUs 102a, 102b, 102c, 102d may include multiple transceivers for communicating with different wireless networks over different wireless links. For example, the WTRU 102c shown in
As shown in
The core network 106 shown in
The RNC 142a in the RAN 103 may be connected to the MSC 146 in the core network 106 via an IuCS interface. The MSC 146 may be connected to the MGW 144. The MSC 146 and the MGW 144 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional landline communications devices.
The RNC 142a in the RAN 103 may also be connected to the SGSN 148 in the core network 106 via an IuPS interface. The SGSN 148 may be connected to the GGSN 150. The SGSN 148 and the GGSN 150 may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.
As noted above, the core network 106 may also be connected to the networks 112, which may include other wired and/or wireless networks that are owned and/or operated by other service providers.
The RAN 104 may include eNode Bs 160a, 160b, 160c, though the RAN 104 may include any number of eNode Bs while remaining consistent with an embodiment. The eNode Bs 160a, 160b, 160c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the eNode Bs 160a, 160b, 160c may implement MIMO technology. Thus, the eNode B 160a, for example, may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 102a.
Each of the eNode Bs 160a, 160b, 160c may be associated with a particular cell (not shown) and may be configured to handle radio-resource-management decisions, handover decisions, scheduling of users in the uplink and/or downlink, and the like. As shown in
The core network 107 shown in
The MME 162 may be connected to each of the eNode Bs 160a, 160b, 160c in the RAN 104 via an S1 interface and may serve as a control node. For example, the MME 162 may be responsible for authenticating users of the VVTRUs 102a, 102b, 102c, bearer activation/deactivation, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c, and the like. The MME 162 may also provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM or WCDMA.
The serving gateway 164 may be connected to each of the eNode Bs 160a, 160b, 160c in the RAN 104 via the S1 interface. The serving gateway 164 may generally route and forward user data packets to/from the WTRUs 102a, 102b, 102c. The serving gateway 164 may also perform other functions, such as anchoring user planes during inter-eNode B handovers, triggering paging if downlink data is available for the VVTRUs 102a, 102b, 102c, managing and storing contexts of the WTRUs 102a, 102b, 102c, and the like.
The serving gateway 164 may also be connected to the PDN gateway 166, which may provide the VVTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.
The core network 107 may facilitate communications with other networks. For example, the core network 107 may provide the VVTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the VVTRUs 102a, 102b, 102c and traditional landline communications devices. For example, the core network 107 may include, or may communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the core network 107 and the PSTN 108. In addition, the core network 107 may provide the WTRUs 102a, 102b, 102c with access to the networks 112, which may include other wired and/or wireless networks that are owned and/or operated by other service providers.
As shown in
The air interface 117 between the WTRUs 102a, 102b, 102c and the RAN 105 may be defined as an R1 reference point that implements the IEEE 802.16 specification. In addition, each of the WTRUs 102a, 102b, 102c may establish a logical interface (not shown) with the core network 109. The logical interface between the WTRUs 102a, 102b, 102c and the core network 109 may be defined as an R2 reference point (not shown), which may be used for authentication, authorization, IP-host-configuration management, and/or mobility management.
The communication link between each of the base stations 180a, 180b, 180c may be defined as an R8 reference point that includes protocols for facilitating WTRU handovers and the transfer of data between base stations. The communication link between the base stations 180a, 180b, 180c and the ASN gateway 182 may be defined as an R6 reference point. The R6 reference point may include protocols for facilitating mobility management based on mobility events associated with each of the WTRUs 102a, 102b, 102c.
As shown in
The MIP-HA 184 may be responsible for IP-address management, and may enable the WTRUs 102a, 102b, 102c to roam between different ASNs and/or different core networks. The MIP-HA 184 may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices. The AAA server 186 may be responsible for user authentication and for supporting user services. The gateway 188 may facilitate interworking with other networks. For example, the gateway 188 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional landline communications devices. In addition, the gateway 188 may provide the WTRUs 102a, 102b, 102c with access to the networks 112, which may include other wired and/or wireless networks that are owned and/or operated by other service providers.
Although not shown in
It will be appreciated that the WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with an embodiment. Also, embodiments contemplate that the base stations 114a and 114b, and/or the nodes that base stations 114a and 114b may represent, such as but not limited to transceiver station (BTS), a Node-B, a site controller, an access point (AP), a home node-B, an evolved home node-B (eNodeB), a home evolved node-B (HeNB), a home evolved node-B gateway, and proxy nodes, among others, may include some or all of the elements depicted in
The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Array (FPGAs) circuits, any other type of integrated circuit (IC), a state machine, and the like. The processor 118 may perform signal coding, data processing, power control, input/output processing, and/or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit/receive element 122. While
The transmit/receive element 122 may be configured to transmit signals to, or receive signals from, a base station (e.g., the base station 114a) over the air interface 116. For example, in one embodiment, the transmit/receive element 122 may be an antenna configured to transmit and/or receive RF signals. In another embodiment, the transmit/receive element 122 may be an emitter/detector configured to transmit and/or receive IR, UV, or visible light signals, as examples. In yet another embodiment, the transmit/receive element 122 may be configured to transmit and receive both RF and light signals. The transmit/receive element 122 may be configured to transmit and/or receive any combination of wireless signals.
In addition, although the transmit/receive element 122 is depicted in
The transceiver 120 may be configured to modulate the signals that are to be transmitted by the transmit/receive element 122 and to demodulate the signals that are received by the transmit/receive element 122. As noted above, the WTRU 102 may have multi-mode capabilities. Thus, the transceiver 120 may include multiple transceivers for enabling the WTRU 102 to communicate via multiple RATs, such as UTRA and IEEE 802.11, as examples.
The processor 118 of the WTRU 102 may be coupled to, and may receive user input data from, the speaker/microphone 124, the keypad 126, and/or the display/touchpad 128 (e.g., a liquid crystal display (LCD) display unit or organic light-emitting diode (OLED) display unit). The processor 118 may also output user data to the speaker/microphone 124, the keypad 126, and/or the display/touchpad 128. In addition, the processor 118 may access information from, and store data in, any type of suitable memory, such as the non-removable memory 130 and/or the removable memory 132. The non-removable memory 130 may include random-access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like. In other embodiments, the processor 118 may access information from, and store data in, memory that is not physically located on the WTRU 102, such as on a server or a home computer (not shown).
The processor 118 may receive power from the power source 134, and may be configured to distribute and/or control the power to the other components in the WTRU 102. The power source 134 may be any suitable device for powering the WTRU 102. As examples, the power source 134 may include one or more dry cell batteries (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li-ion), and the like), solar cells, fuel cells, and the like.
The processor 118 may also be coupled to the GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to, or in lieu of, the information from the GPS chipset 136, the WTRU 102 may receive location information over the air interface 116 from a base station (e.g., base stations 114a, 114b) and/or determine its location based on the timing of the signals being received from two or more nearby base stations. The WTRU 102 may acquire location information by way of any suitable location-determination method while remaining consistent with an embodiment.
The processor 118 may further be coupled to other peripherals 138, which may include one or more software and/or hardware modules that provide additional features, functionality and/or wired or wireless connectivity. For example, the peripherals 138 may include an accelerometer, an e-compass, a satellite transceiver, a digital camera (for photographs or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, and the like.
Communication interface 192 may include one or more wired communication interfaces and/or one or more wireless-communication interfaces. With respect to wired communication, communication interface 192 may include one or more interfaces such as Ethernet interfaces, as an example. With respect to wireless communication, communication interface 192 may include components such as one or more antennae, one or more transceivers/chipsets designed and configured for one or more types of wireless (e.g., LTE) communication, and/or any other components deemed suitable by those of skill in the relevant art. And further with respect to wireless communication, communication interface 192 may be equipped at a scale and with a configuration appropriate for acting on the network side—as opposed to the client side—of wireless communications (e.g., LTE communications, Wi-Fi communications, and the like). Thus, communication interface 192 may include the appropriate equipment and circuitry (which may include multiple transceivers) for serving multiple mobile stations, UEs, or other access terminals in a coverage area.
Processor 194 may include one or more processors of any type deemed suitable by those of skill in the relevant art, some examples including a general-purpose microprocessor and a dedicated DSP.
Data storage 196 may take the form of any non-transitory computer-readable medium or combination of such media, some examples including flash memory, read-only memory (ROM), and random-access memory (RAM) to name but a few, as any one or more types of non-transitory data storage deemed suitable by those of skill in the relevant art may be used. As depicted in
In some embodiments, the network-entity functions described herein are carried out by a network entity having a structure similar to that of network entity 190 of
Note that various hardware elements of one or more of the described embodiments are referred to as “modules” that perform or execute various functions that are described herein in connection with the respective modules. As used herein, a module includes hardware (e.g., one or more processors, one or more microprocessors, one or more microcontrollers, one or more microchips, one or more application-specific integrated circuits (ASICs), one or more field programmable gate arrays (FPGAs), one or more memory devices) deemed suitable by those of skill in the relevant art for a given implementation. Each described module may also include instructions executable for carrying out the one or more functions described as being carried out by the respective module, and those instructions may take the form of or include hardware (hardwired) instructions, firmware instructions, software instructions, and/or the like, and may be stored in any suitable non-transitory computer-readable medium or media, such as commonly referred to as RAM or ROM.
Although features and elements are described above in particular combinations, one of ordinary skill in the art will appreciate that each feature or element may be used alone or in any combination with the other features and elements. In addition, the methods described herein may be implemented in a computer program, software, or firmware incorporated in a computer-readable medium for execution by a computer or processor. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), a register, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks, and digital versatile disks (DVDs). A processor in association with software may be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.
Claims
1. A method for selecting a route for a group of vehicles, comprising:
- identifying a plurality of available platoon configurations for the group of vehicles;
- determining a plurality of route options from a first location to a second location, each route option comprising a plurality of segments;
- determining, for each of the plurality of segments of the plurality of route options, whether the respective segment supports at least one of the identified platoon configurations;
- selecting, from among the plurality of route options, a route for which each segment of the selected route has been determined to support at least one of the identified platoon configurations; and
- communicating the selected route to at least one vehicle in the group of vehicles.
2. The method of claim 1, further comprising:
- selecting, for each segment along the selected route, a corresponding platoon configuration that is supported by that segment; and
- communicating the selected platoon configurations to the at least one vehicle in the group of vehicles.
3. The method of claim 2, wherein communicating the selected platoon configurations occurs before the group of vehicles traverses the selected route.
4. The method of claim 1, further comprising identifying at least a first road-side unit (RSU) along at least a first one of the route options, wherein the first route option is selected as the selected route option only if a determination is made that the first RSU supports at least one of the identified platoon configurations.
5. The method of claim 4, wherein determining whether the first RSU supports at least one of the identified platoon configurations comprises determining whether the RSU is capable of instructing a traffic light associated with the first RSU to increase a green light time to accommodate at least one platoon configuration of the group of vehicles.
6. The method of claim 1, wherein selecting the route comprises:
- eliminating route options from the plurality of route options that contain at least one segment that does not support at least one platoon configuration of a group of vehicles;
- calculating a route score for each of the plurality of route options not eliminated; and
- selecting the route from the plurality of route options wherein the route score of the selected route is above a threshold.
7. The method of claim 6, further comprising querying a service to identify, for at least one of the segments of the plurality of route options, information specifying at least one platoon configuration supported by the segment.
8. The method of claim 6, wherein calculating the route score is based in part on a vehicle category score for each vehicle in the group of vehicles, a level of automation for each vehicle in the group of vehicles, and a maximum number of vehicles allowed in a platoon for each segment of the plurality of route options not eliminated.
9. The method of claim 6, wherein selecting the route is based further on which vehicles of the group will leave the group prior to arriving at the second location.
10. The method of claim 6, wherein selecting the route is based in part on time of arrival of the group of vehicles at the second location.
11. The method of claim 1, wherein determining whether the respective segment supports at least one of the identified platoon configurations comprises determining if at least one of the identified platoon configurations has a platoon length that is less than a maximum platoon length for the respective segment.
12. The method of claim 1, further comprising receiving information restricting platoon size for a segment of at least one route of the plurality of route options, wherein selecting the route is based in part on the received information restricting platoon size.
13. The method of claim 1, further comprising navigating the selected route.
14. The method of claim 1, wherein identifying the plurality of available platoon configurations is based in part on quantity of vehicles in the group, length of vehicles in the group, and a level of automation for each vehicle.
15. A device comprising:
- a processor; and
- a non-transitory computer-readable medium storing instructions that are operative, when executed on the processor, to perform the functions of: identifying a plurality of available platoon configurations for the group of vehicles; determining a plurality of route options from a first location to a second location, each route option comprising a plurality of segments; determining, for the plurality of segments of the plurality of route options, whether the respective segment supports at least one of the identified platoon configurations; selecting, from among the plurality of route options, a route for which each segment of the selected route has been determined to support at least one of the identified platoon configurations; and communicating the selected route to at least one vehicle in the group of vehicles.
Type: Application
Filed: Dec 6, 2017
Publication Date: Feb 27, 2020
Patent Grant number: 11293765
Inventors: Mikko Tarkiainen (Tampere), Matti Kutila (Tampere), Ari Virtanen (Lempäälä), Pertti Peussa (Tampere)
Application Number: 16/461,311
