WO2018035145A1 - Procédé de changement de véhicule de tête de peloton de véhicules - Google Patents

Procédé de changement de véhicule de tête de peloton de véhicules Download PDF

Info

Publication number
WO2018035145A1
WO2018035145A1 PCT/US2017/046993 US2017046993W WO2018035145A1 WO 2018035145 A1 WO2018035145 A1 WO 2018035145A1 US 2017046993 W US2017046993 W US 2017046993W WO 2018035145 A1 WO2018035145 A1 WO 2018035145A1
Authority
WO
WIPO (PCT)
Prior art keywords
platoon
vehicle
driver
configuration
lead
Prior art date
Application number
PCT/US2017/046993
Other languages
English (en)
Inventor
Matti Kutila
Mikko Tarkiainen
Pertti PEUSSA
Ari Virtanen
Samian Kaur
Serhad Doken
Original Assignee
Pcms Holdings, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Pcms Holdings, Inc. filed Critical Pcms Holdings, Inc.
Publication of WO2018035145A1 publication Critical patent/WO2018035145A1/fr

Links

Classifications

    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05D—SYSTEMS FOR CONTROLLING OR REGULATING NON-ELECTRIC VARIABLES
    • G05D1/00—Control of position, course or altitude of land, water, air, or space vehicles, e.g. automatic pilot
    • G05D1/02—Control of position or course in two dimensions
    • G05D1/021—Control of position or course in two dimensions specially adapted to land vehicles
    • G05D1/0287—Control of position or course in two dimensions specially adapted to land vehicles involving a plurality of land vehicles, e.g. fleet or convoy travelling
    • G05D1/0291—Fleet control
    • G05D1/0295—Fleet control by at least one leading vehicle of the fleet
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60W—CONJOINT CONTROL OF VEHICLE SUB-UNITS OF DIFFERENT TYPE OR DIFFERENT FUNCTION; CONTROL SYSTEMS SPECIALLY ADAPTED FOR HYBRID VEHICLES; ROAD VEHICLE DRIVE CONTROL SYSTEMS FOR PURPOSES NOT RELATED TO THE CONTROL OF A PARTICULAR SUB-UNIT
    • B60W30/00—Purposes of road vehicle drive control systems not related to the control of a particular sub-unit, e.g. of systems using conjoint control of vehicle sub-units, or advanced driver assistance systems for ensuring comfort, stability and safety or drive control systems for propelling or retarding the vehicle
    • B60W30/14—Adaptive cruise control
    • B60W30/16—Control of distance between vehicles, e.g. keeping a distance to preceding vehicle
    • B60W30/165—Automatically following the path of a preceding lead vehicle, e.g. "electronic tow-bar"
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60W—CONJOINT CONTROL OF VEHICLE SUB-UNITS OF DIFFERENT TYPE OR DIFFERENT FUNCTION; CONTROL SYSTEMS SPECIALLY ADAPTED FOR HYBRID VEHICLES; ROAD VEHICLE DRIVE CONTROL SYSTEMS FOR PURPOSES NOT RELATED TO THE CONTROL OF A PARTICULAR SUB-UNIT
    • B60W50/00—Details of control systems for road vehicle drive control not related to the control of a particular sub-unit, e.g. process diagnostic or vehicle driver interfaces
    • B60W50/0097—Predicting future conditions
    • G—PHYSICS
    • G08—SIGNALLING
    • G08G—TRAFFIC CONTROL SYSTEMS
    • G08G1/00—Traffic control systems for road vehicles
    • G08G1/22—Platooning, i.e. convoy of communicating vehicles
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60W—CONJOINT CONTROL OF VEHICLE SUB-UNITS OF DIFFERENT TYPE OR DIFFERENT FUNCTION; CONTROL SYSTEMS SPECIALLY ADAPTED FOR HYBRID VEHICLES; ROAD VEHICLE DRIVE CONTROL SYSTEMS FOR PURPOSES NOT RELATED TO THE CONTROL OF A PARTICULAR SUB-UNIT
    • B60W2540/00—Input parameters relating to occupants
    • B60W2540/22—Psychological state; Stress level or workload
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60W—CONJOINT CONTROL OF VEHICLE SUB-UNITS OF DIFFERENT TYPE OR DIFFERENT FUNCTION; CONTROL SYSTEMS SPECIALLY ADAPTED FOR HYBRID VEHICLES; ROAD VEHICLE DRIVE CONTROL SYSTEMS FOR PURPOSES NOT RELATED TO THE CONTROL OF A PARTICULAR SUB-UNIT
    • B60W2540/00—Input parameters relating to occupants
    • B60W2540/26—Incapacity
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60W—CONJOINT CONTROL OF VEHICLE SUB-UNITS OF DIFFERENT TYPE OR DIFFERENT FUNCTION; CONTROL SYSTEMS SPECIALLY ADAPTED FOR HYBRID VEHICLES; ROAD VEHICLE DRIVE CONTROL SYSTEMS FOR PURPOSES NOT RELATED TO THE CONTROL OF A PARTICULAR SUB-UNIT
    • B60W2554/00—Input parameters relating to objects
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60W—CONJOINT CONTROL OF VEHICLE SUB-UNITS OF DIFFERENT TYPE OR DIFFERENT FUNCTION; CONTROL SYSTEMS SPECIALLY ADAPTED FOR HYBRID VEHICLES; ROAD VEHICLE DRIVE CONTROL SYSTEMS FOR PURPOSES NOT RELATED TO THE CONTROL OF A PARTICULAR SUB-UNIT
    • B60W2554/00—Input parameters relating to objects
    • B60W2554/40—Dynamic objects, e.g. animals, windblown objects
    • B60W2554/404—Characteristics
    • B60W2554/4041—Position
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60W—CONJOINT CONTROL OF VEHICLE SUB-UNITS OF DIFFERENT TYPE OR DIFFERENT FUNCTION; CONTROL SYSTEMS SPECIALLY ADAPTED FOR HYBRID VEHICLES; ROAD VEHICLE DRIVE CONTROL SYSTEMS FOR PURPOSES NOT RELATED TO THE CONTROL OF A PARTICULAR SUB-UNIT
    • B60W2554/00—Input parameters relating to objects
    • B60W2554/40—Dynamic objects, e.g. animals, windblown objects
    • B60W2554/406—Traffic density
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60W—CONJOINT CONTROL OF VEHICLE SUB-UNITS OF DIFFERENT TYPE OR DIFFERENT FUNCTION; CONTROL SYSTEMS SPECIALLY ADAPTED FOR HYBRID VEHICLES; ROAD VEHICLE DRIVE CONTROL SYSTEMS FOR PURPOSES NOT RELATED TO THE CONTROL OF A PARTICULAR SUB-UNIT
    • B60W2556/00—Input parameters relating to data
    • B60W2556/45—External transmission of data to or from the vehicle
    • B60W2556/65—Data transmitted between vehicles

Definitions

  • platooning will be one of the first targets concerning automation of commercial heavy vehicles.
  • platooning is subject to various practical and technical requirements.
  • passenger cars are generally not allowed to follow a platoon of heavy vehicles, and it may be required that the front vehicle of a platoon have a driver.
  • One issue that is likely to arise is how autonomous platoons with 3-7 vehicles will account for platoon configuration changes when drivers cannot pass a whole platoon at one time.
  • On a multi-lane highway there are separate lanes that can be used for passing a platoon.
  • platoons are intended to be used not only on multi-lane highways, but also on, for example, a two-lane country road with hills and on-coming traffic.
  • Ensuring latency times for splitting and merging platoons may be a challenge when the lead vehicle is changed. It is desirable to determine, within a few seconds of a platoon becoming fragmented, which vehicle will be assigned the lead driver (or supervisor) role.
  • Current platooning applications are based mostly on information received from vehicle-to- vehicle (V2V) communication channels and longitudinal distance detection systems (e.g., radar). However, these systems focus on vehicle kinetic data by optimizing smooth travelling, and these systems do not account for reconfiguring a platoon's structure while driving.
  • V2V vehicle-to- vehicle
  • radar longitudinal distance detection systems
  • Methods and systems disclosed herein are used to support autonomous vehicle platoons for a platoon structure reconfiguration.
  • vehicle platoons split, merge, or move to two-lane roads.
  • the platoon leader or supervisor may change to a different driver.
  • Such situations may occur due to an incident or obstacle in the road, a sensor system failure, or an exiting of vehicles to follow another route.
  • An exemplary system uses existing drivers and operators to support situation awareness systems to continue an autonomous driving mode without disbanding a platoon.
  • the system may be triggered by abnormal traffic situations reported by other vehicles to an intelligent transport system (ITS) service station or to the leader of the platoon.
  • ITS intelligent transport system
  • the lead vehicle determines whether to use support from a human and selects an available driver to take over the lead driver (or supervisor) role.
  • a platoon may already include a driver who, via an application (such as a "see through” application as described below), may take over control of the platoon and support splitting the platoon into mini-platoons.
  • One embodiment continuously updates a table accessible to the lead vehicle (the vehicle which supervises a platoon) concerning driver availability to take over platoon supervision.
  • One embodiment continuously monitors whether to split or merge a platoon and whether a driver may be able to take over platoon supervision.
  • Methods and systems disclosed herein receive, from each vehicle associated with a platoon in a first platoon configuration, information regarding driver availability of a driver associated respectively with each vehicle. Responsive to a determination that the first platoon configuration is not appropriate for an upcoming route segment, methods and systems disclosed herein: (1) determine platoon configuration options that are appropriate for the upcoming route segment; (2) select a second platoon configuration such that the driver availability received by a vehicle is compatible with serving a lead driver role in the second platoon configuration; and (3) transmit platoon configuration information about the second platoon configuration to each vehicle associated with the platoon to instruct the vehicles to operate in accordance with the second platoon configuration.
  • FIG. 1 is a concept view schematic of a collaborative vehicle platooning scenario.
  • FIG. 2 is an exemplary user interface diagram of a user interface displaying a lead driver role message.
  • FIG. 3 is a plan view schematic of a platoon split for a scenario where an obstacle partially blocks a lane.
  • FIG. 4 is a system block diagram of communication between two or more autonomous vehicles, an ITS service station, and another car.
  • FIG. 5 is a message sequence diagram for a method of updating a driver availability look-up table.
  • FIG. 6 is a message sequence diagram for a method of splitting a platoon and setting up a new leader.
  • FIG. 7 is a message sequence diagram for a method of setting up a new leader of a platoon.
  • FIG. 8 is a flowchart for a method of updating a driver availability look-up table.
  • FIG. 9 is a flowchart for a method of splitting a platoon and determining a new leader.
  • FIG. 10 is an exemplary user interface diagram for displaying messages for changing lane alignment and changing vehicle speed.
  • FIG. 11 is a plan view schematic illustrating a method of setting up a new leader of a platoon.
  • FIG. 12A depicts an example communications system in which one or more disclosed embodiments may be implemented.
  • FIG. 12B depicts an example wireless transmit/receive unit (WTRU) that may be used within the communications system of FIG. 12A.
  • WTRU wireless transmit/receive unit
  • FIG. 12C depicts an example radio access network (RAN) and an example core network that may be used within the communications system of FIG. 12 A.
  • RAN radio access network
  • FIG. 12D depicts a second example RAN and a second example core network that may be used within the communications system of FIG. 12 A.
  • FIG. 12E depicts a third example RAN and a third example core network that may be used within the communications system of FIG. 12 A.
  • FIG. 12F depicts an exemplary network entity that may be used within the communication system of FIG. 12 A.
  • 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.
  • autonomous vehicles in these cases stop autonomous driving mode and request drivers to resume control. Alertness of drivers varies depending on drowsiness level and engagement with non-driving tasks (e.g., reading a newspaper or surfing the Internet).
  • non-driving tasks e.g., reading a newspaper or surfing the Internet.
  • semi-autonomous driving people tend to start thinking about something other than driving. Reverting driving back to a person takes away from the person's ability to do other tasks and may be dangerous if the person is drowsy.
  • a system may receive via a V2X channel from other vehicles or from an ITS service station a message requesting a platoon configuration change. This message may be sent for safety reasons or for maintaining autonomous platooning mode.
  • a platoon may be split into two platoons for multiple reasons, such as overtaking the lead vehicle (or front vehicle) in two sections or passing through road maintenance work where passenger cars use one lane and trucks use another lane.
  • Exemplary methods allow vehicle platoons to survey real world road conditions (also called incidents in this specification) and determine when a platoon split or merge is beneficial. Mini-platoons may pass the incident more easily than a larger platoon, while manual driving may be avoided. Such methods may reconfigure a platoon (even if all vehicles do not have a driver) by assigning a lead driver (or supervisor) role to a vehicle in which a driver is available behind the steering wheel. Such a lead driver role may be assigned in some embodiments even to a driver whose vehicle is not the front vehicle.
  • a system operates to reconfigure (split and merge a platoon into multiple parts) based on detected incidents.
  • trigger data that activates platoon reconfiguration may be received from a V2X communication channel or a vehicle environment perception system.
  • a system may generate different types of platoons, such as splitting into two or more smaller platoons or switching to two-lane platooning to take a detour to avoid an accident (or other incident).
  • An exemplary system operates to recognize and categorize drivers in a platoon according to a driver's availability to take over the lead driver (or supervisor) role.
  • FIG. 1 is a plan view schematic of a scenario 170 where a platoon is split when a non- platoon vehicle passes only part of the platoon.
  • the scenario may occur on a two-lane road where a non-platoon vehicle 175 starts to pass the platoon. Before the non-platoon vehicle 175 finishes passing the platoon, an on-coming car 171 appears in the opposite lane. The non-platoon vehicle 175 returns to the right hand lane and splits the platoon in the process.
  • three of the platoon vehicles 172, 174, 176 have drivers (shown with a checkmark), while two vehicles 173, 177 have no driver available (shown with an "x").
  • a driver is available in some vehicles to take over a lead driver role in a platoon if the platoon is split into multiple mini- platoons.
  • the lead vehicle 172 (the one which supervises the platoon) stores a driver availability look-up table (or "look-up table"), which may be a plurality of memory locations, concerning availability (and capability) of drivers to take over platoon supervision if the platoon is reconfigured.
  • Driver availability may be based on whether a driver is distracted, drowsy (or lacking a safe level of alertness), or not behind the steering wheel.
  • the look-up table is continuously-updated. If a split function is activated, a system checks the look-up table to determine which vehicles may be assigned the lead driver role in the platoon. In some embodiments, a "see-through" application or other user interface is present in all vehicles.
  • a lead vehicle 172 with an in-vehicle environment 178 may communicate via V2X communication 193 to a vehicle 174 with a driver present and an in-vehicle environment 179.
  • the vehicle 174 may communicate via V2X communication 195 to a vehicle 176 selected to be a lead vehicle of a sub-platoon of the platoon.
  • An in-vehicle view 191 of the first lead vehicle 172 may be communicated to the second lead vehicle 176.
  • Exemplary technology that may be used to implement a see-through application is described in, for example, Gomes, F. Vieira, and M. Ferreira, The See-Through System: From Implementation to Test-Drive, IEEE VEHICULAR NETWORKING CONFERENCE (VNC), 14- 16 NOV. 2012, SEOUL, SOUTH KOREA, (2012).
  • the see-through application or other application may also operate to display reasons for a platoon split.
  • the user interface may be used to show a message received via a V2X channel regarding an incident (such as road construction or an on-coming vehicle) and to enable a driver to have enough time to make an adjustment.
  • FIG. 2 is an exemplary user interface 200 for displaying a message 201 asking if the driver is able to accept a lead driver role, such as an interface of a see-through application.
  • the system may display information on the reason for splitting. For some embodiments, underneath a text box displaying the message, two buttons 202, 203 are displayed. The user may press "Yes” or “No” to accept or reject, respectively, the lead driver role when the platoon is split. For other embodiments, an external keyboard is used by the driver to accept or reject the lead driver role.
  • the see-through application may send an acknowledgement message to the other platoon vehicles that indicates whether the driver accepts or rejects the offer to be a platoon leader.
  • FIG. 2 also shows an example user interface display for a narrowing of a lane.
  • the user interface displays a warning message 204 on a video screen with a view of the road segment ahead.
  • the warning message shows the text line "Lane width ⁇ 3 m" underneath a warning triangle symbol.
  • an in-vehicle computer when an in-vehicle computer detects an incident or lane obstacle that may result in a platoon split, the computer will calculate an optimal number of mini- platoons.
  • Other vehicles may be allowed to be assigned the lead driver (or supervisor) role after checking which vehicles are available. Also, a system will minimize manual driving and generate an optimal number of mini-platoons.
  • FIG. 3 shows an example 300 where an obstacle 322 partially blocks a lane and leaves only passenger cars 3 16, 320 with enough room to pass the obstacle.
  • Big trucks 302, 304, 308 will move to a different lane to avoid the obstacle 322 as shown on the right of FIG. 3 as trucks 3 12, 314, 3 18.
  • passenger cars 306, 3 10 form a new mini-platoon of cars 3 16, 320 on the right side of FIG. 3.
  • the new mini-platoon of cars 3 16, 320 may make changes, such as slowing down and making maneuvers to pass the obstacle 322, that are not performed by the platoon of big trucks 3 12, 3 14, 3 18.
  • the platoon leader 302 may continue as platoon leader 1 (3 12) of the big trucks 3 12, 3 14, 3 18 while platoon leader 2 (3 16) leads the mini-platoon of cars 3 16, 320.
  • FIG. 3 shows a scenario 300 where an obstacle 322 partly blocks a lane being used by a vehicle platoon.
  • a system interacts with two or more vehicles that are part of the platoon.
  • a vehicle in the platoon may detect an obstacle in the road. The existence of this obstacle may be communicated to other vehicles and to an ITS service station.
  • the lead vehicle 302 receives information from other vehicles 304, 306, 308, 310 in the platoon or from an ITS service station via V2X communication of an incident detected message.
  • the warning may be received when the lead vehicle 302, 312 is about 300 - 800 m away 324 from the obstacle 322. This distance 324 enables the platoon to have time to react to the incident.
  • the platoon will be split into two or more mini -platoons.
  • An exemplary size platoon may be 3 to 10 vehicles, while a mini-platoon may be even 2 vehicles.
  • a system may react to a situation where a platoon may use driver interaction.
  • One option has a system sending platoon leader request messages to platoon vehicles with a compatible driver. These messages are sent to determine if another vehicle driver will take over control and supervision of the platoon when the state of the lead vehicle driver is drowsy or distracted, for example.
  • Another option splits the platoon into two or more mini- platoons and determines lead vehicle drivers (or supervisors) for each mini-platoon from the group of drivers who are available, behind the wheel, properly licensed, and not too distracted to take over the driving task. Two platoons or mini-platoons may merge together for efficiency, safety, or other criteria.
  • driver state analysis is executed continuously as a separate process that uses a look-up table stored on the lead (or first) vehicle of the platoon. Moreover, driver background information is added to the look-up table to communicate to the driver of the lead vehicle the level of driving experience of each driver in the platoon.
  • a system checks the look-up table to determine what vehicle and driver support is available. A support message is sent to only vehicles with drivers who may be available to take over the lead vehicle position for the platoon.
  • Minimizing latency time reduces risk when control of the platoon is handed over to a new driver.
  • the driver Via the vehicle human-machine interface (HMI), the driver acknowledges that he or she will take over the control of the platoon.
  • the selected driver receives perception data from the lead vehicle of the platoon, and this data is displayed via the see-through application or another available user interface environment. Incident information is also provided for the vehicle driver.
  • An exemplary system operates to maximize use of autonomous mode for platooning vehicles while minimizing interventions with drivers and vehicle occupants.
  • FIG. 4 is a block diagram 400 showing interface components and system communication connections.
  • Each platooning vehicle 402, 404 (vehicles 1, 2, and any additional vehicle in the platoon) may have the following modules and components: a communications unit
  • a communications unit 412, 420 may use a data exchange channel (such as DSRC and 5G) 410 to transmit and receive data to and from platooning vehicles 402, 404, other vehicles 406, and ITS service stations 408.
  • An HMI module 414, 422 may show the status of the environment perception data, incident messages, and video from the lead vehicle or other vehicles in the platoon. The HMI 414, 422 also receives an acknowledgment message from another platoon vehicle that the driver of that vehicle accepts or rejects a lead driver role.
  • a driver state analysis module 416, 424 monitors a driver's availability (based on workload, drowsiness, and being in the driver's seat) and provides support to a vehicle computer system.
  • the module 416, 424 may also store in memory driver characteristics, such as professional truck driver status, young driver status, and experience as a driver, and communicate those characteristics to other modules and systems.
  • Each driver state analysis module 416, 424 transmits updates to the lead vehicle to store in a look-up table.
  • the driver availability look-up table may be continuously or regularly updated with driver availability (which includes driver alertness level/state) for each vehicle in the platoon.
  • a platooning function is a module that controls platoon control parameters, such as distance, speed, direction, lane alignment, and IDs of vehicles in the platoon) and functionality level (manual or autonomous driving mode).
  • a communications unit 428 For other vehicles 406 (which may or may not be part of the platoon) that detect a road incident, two modules may be used: a communications unit 428 and a perception system 430.
  • a lead vehicle in a platoon may also communicate with other vehicles outside the platoon as the platoon approaches such other vehicles. These other vehicles 406 are labeled as "Car 2: Other Car or Vehicle.” This vehicle 406 also may be a truck or other vehicle for some embodiments.
  • a communications unit 428 is used to receive and transmit data with platooning vehicles.
  • a perception system 430 detects road hazards, incidents (such as accidents), and obstructions and objects around a vehicle or in a lane of traffic.
  • Other vehicles 406 provide driver state analysis information continuously to the lead vehicle which hosts decision making and control functions for the whole platoon.
  • the lead vehicle may have the best visual view for events in front of the platoon.
  • Video from the lead vehicle may be displayed on a see-through video display module within each vehicle in the platoon. For some embodiments, when a new leader (or supervisor) is determined to lead a platoon, the see-through video display may switch to another vehicle.
  • An ITS service station 408 may use two modules as part of a unit's interactions with other system components: a communications unit 432 and a traffic and road data module 434.
  • a communications unit 432 receives and transmits data from and to platooning vehicles.
  • a traffic and road data module 434 is a database for storing in memory traffic and road incidents. This database 434 may be used by the communications unit to transmit and receive data for use by platooning vehicles.
  • FIG. 5 is a message sequence diagram 500 for updating a driver availability look-up table.
  • the look-up table may be stored in the lead vehicle 502 for a platoon.
  • a lead vehicle 502 sends a RequestDriverState message 506 to every other vehicle 504 in the platoon. For some embodiments, this message 506 is sent on a periodic basis to each other vehicle 504 in the platoon.
  • This request message 506 pings other vehicles 504 for updates to a driver's state of availability.
  • Other vehicles 504 receive these request messages 506 and analyze a driver's state of availability 508.
  • Other vehicles 504 respond to RequestDriverState messages 506 with DriverState messages 510.
  • the state of the driver is stored by the on-board driver monitoring unit.
  • the driver monitoring unit may include cameras for assessing driver facial features, speed, and acceleration data for profiling the driver.
  • the driver monitoring analysis may also be based on vehicle-based parameters, such as speed variation, micro-steering, accelerations, and decelerations.
  • a driver state analysis is done by displaying a message on an FDVII and recording the driver' s response to a driver availability message.
  • a DriverState response message may contain fields for vehicle ID and driver status.
  • the vehicle ID is an identification code for a vehicle in a platoon
  • the driver status is a value corresponding to the state of the driver (drowsy, distracted, or no driver available).
  • An UpdateLookUpTable command 512 is a command sent by a lead vehicle 502 to a module updating the driver availability look-up table.
  • the table may be stored in the lead vehicle 502. This table is used to determine a driver for leading a platoon if an existing lead driver (or supervisor) requests a change.
  • This message 512 contains three fields: NumberPlatooningVehicles, DriverStateLookUpTable, and DriverState.
  • the NumberPlatooningVehicles is the number of vehicles in the platoon. This field is also the size of the DriverStateLookUpTable.
  • the DriverStateLookUpTable is a series of values holding the state of each driver in the platoon.
  • the DriverStateLookUpTable field may be a pointer to a memory location where the table is stored. For each entry in the DriverStateLookUpTable, the state of each platooning vehicle's driver is stored. This DriverState variable may be drowsy, distracted, or no driver available.
  • Driver alertness may be determining using techniques such as detecting human facial features, in-vehicle steering activity, and longitudinal speed variation parameters using methods described in, for example, M. Kutila, M. Jokela, G. Markkula, and M. R. Rue, Driver Distraction Detection with a Camera Vision System, Vol. VI PROCEEDINGS OF THE IEEE INTERNATIONAL CONFERENCE ON IMAGE PROCESSING (ICIP) 201-204 (Sep. 16-19, 2007).
  • Another embodiment may use a decomposed component of a steering wheel control signal to determine whether a driver is alert or drowsy using, for example, techniques described in U.S. Patent 8,519,853, entitled "Unobtrusive Driver Drowsiness Detection System and Method.”
  • FIG. 6 is a message sequence diagram 600 for a scenario where a platoon is split into two or more mini-platoons.
  • a lead vehicle 604 sends a RequestlncidentMap message 608 to a trigger system 602.
  • a trigger system (or trigger) 602 for reconfiguring a platoon or selecting a new lead (or supervisor) vehicle may determine whether a particular driving scenario may benefit from a reconfiguration of a platoon.
  • the trigger system 602 responds to the RequestlncidentMap message 608 with an IncidentMap message 610.
  • This message 610 communicates incidents (both dynamic and static) in front of the lead vehicle 604 of a platoon in response to a request by the lead vehicle 604.
  • the message content may use the format described in ETSI Technical Report 102 863, Intelligent Transport Systems (ITS): Vehicular Communications: Basic Set of Applications: Local Dynamic Map (LDM): Rationale for and Guidance on Standardization, ETSI TECHNICAL REPORT 102 863 (2011) (Section 7.5.3 : Location and Dimensions of Hazard, Version 1.1.1, 2011-08).
  • the message contains three fields: Location, Hazard Type, and Traffic Status.
  • the Location field contains the location of hazard event (or incident).
  • the Hazard Type field is the type of hazard (congestion, accident, road work, narrowing of the road, and 31 other conditions listed in the ETSI Technical Report 102 863).
  • the Traffic Status field contains the status of traffic (such as queuing traffic, slow traffic, and 6 other conditions listed in the ETSI Technical Report 102 863).
  • Other embodiments also contain Lane Identifier and Report Propagation fields mentioned in ETSI Technical Report 102 863.
  • the Lane Identifier field is the highway lane affected by the hazard.
  • the Report Propagation field contains the direction and range of propagation of the hazard.
  • a driver availability check 612 may be performed by reading a look-up table stored in memory and determining a compatible driver to be a new lead vehicle of the platoon.
  • a RequestPlatoonLeader message 614 is transmitted from the lead vehicle to another vehicle in the platoon. This message 614 requests a driver associated with a selected driver to take over control of a platoon. The driver replies via the HMI display, and an Acknowledgement message 616 is sent back to the lead vehicle 604.
  • An Acknowledgement message 616 is a status message that indicates whether the driver accepts or rejects the request to take over the lead driver role for the platoon. This message field may take a value of either yes (accept) or no (reject).
  • PlatoonSplitCommand message 618 is sent to each vehicle in the platoon.
  • the PlatoonSplitCommand message 618 contains at least 4 different fields: NumberOfPlatoons, PlatoonLeaderlD, Platoon Vector 1, and PlatoonVector2.
  • the NumberOfPlatoons field is the number of platoons after the split.
  • the PlatoonLeaderlD field is the vehicle ID of the vehicles that are new lead vehicles.
  • PlatoonVectorl field contains the vehicle IDs for the vehicles that will be in mini -platoon number 1.
  • PlatoonVector2 field contains the vehicle IDs for the vehicles that will be in mini-platoon number 2.
  • More Platoon Vector fields will be included in the message if there will be 3 or more mini-platoons after the split.
  • each vehicle in the platoon is commanded to complete the reconfiguration.
  • This reconfiguration may be a splitting of a platoon, a combining of the platoon with another platoon, or a reassignment of the lead driver role.
  • a desirable platoon configuration may be determined by using techniques describe in U.S. Patent 8,352, 112, entitled "Autonomous Vehicle Management.”
  • the process of determining lead vehicle drivers determines a ranked order of compatible drivers for a lead driver role. This order may be determined, for example, based on a vehicle's location within the platoon, the sensor abilities of a vehicle, and the driver's driving ability.
  • a compatible driver is one that is available, behind the wheel, properly licensed, and not distracted to take over the driving task.
  • the lead vehicle 604 transmits a RequestPlatoonLeader (or lead driver role request) message 614 to the vehicle with the highest ranked compatible driver.
  • the vehicle 606 with the compatible driver responds with an Acknowledgement (or lead driver role response) message 616.
  • the process repeats and transmits a RequestPlatoonLeader (lead driver role request) 614 message to the next highest ranked compatible driver. If the vehicle responded with an accept field value in the Acknowledgement message 616, the lead vehicle 604 transmits a PlatoonSplitCommand message 618 to each vehicle 606 in the platoon.
  • the lead vehicle 604 may disband the platoon by sending a message to each vehicle in the platoon to switch to manual driving mode.
  • the process of determining lead vehicle drivers for a new platoon configuration is performed by a lead vehicle 604 of the current platoon configuration.
  • the process of determining lead vehicle drivers for a new platoon configuration is performed by an external sever.
  • Incident data is transmitted to the lead vehicle and displayed to inform the driver of a situation that may cause a platoon to be split into two or more mini-platoons.
  • a PerceptionData message 620 is sent from the lead vehicle to a platoon vehicle. This message contains perception data for visualizing an object undetected (or unknown) by platoon vehicles other than the lead vehicle.
  • the message has 2 fields: UnknownObject and ObjectPositon.
  • UnknownObject field contains information concerning the undetected (or unknown) object (such as size or color).
  • the ObjectPosition field is the position of the object in the World Geodetic System 1984 (WGS84) coordinate system. The coordinates are in the global frame of the platoon.
  • a SendVideoData message 622 is sent from the lead vehicle 604 to another vehicle 606 in the platoon.
  • the message 622 contains video data captured by the lead vehicle 604 in assessing an undetected (or unknown) object.
  • the message 622 has one field, VideoDataStream.
  • the VideoDataStream field is a video data stream that is recorded by a camera attached to the lead vehicle.
  • a PlatoonSplitStatus message 624 is sent from the platoon vehicle back to the former lead vehicle. The message communicates that the vehicle's portion of the platoon split is completed and a new lead (or supervisor) vehicle has been assigned.
  • FIG. 7 is a message sequence diagram 700 of a system when the lead driver role is changed to a new vehicle and driver.
  • FIG. 7 is similar to FIG. 6 except that FIG. 7 applies to a change in the lead vehicle 704 for the platoon but no other reconfiguration of the platoon, while FIG. 6 applies to a split in a platoon vehicle layout.
  • FIG. 7's scenario has all the same messages as FIG. 6 except for the transmitting of PlatoonSplitCommand and PlatoonSplitStatus messages.
  • a Lead Vehicle 704 sends a RequestlncidentMap message 708 to a Trigger System 702, which responds with an IncidentMap message 710.
  • the Lead Vehicle 704 checks for driver availability 712 and sends a RequestDriverSupport message 714 to a Platoon Vehicle 706.
  • a Platoon Vehicle 706 responds with an Acknowledgement 716.
  • the Lead Vehicle 704 sends a PerceptionData message 718 and a SendVideoData message 720 to a Platoon Vehicle 706 corresponding to the new platoon leader.
  • the Platoon Vehicle 706 executes driving commands 722 to move into position as the new platoon leader.
  • FIG. 8 is a flowchart 800 of the steady state driver state analysis system that monitors driver availability and updates a driver availability look-up table. If a plurality of vehicles forms a platoon and switches to platoon mode 802, several initial conditions exist. Each vehicle in the platoon is in platooning mode. Vehicle 1 is the front (or lead) vehicle and master (or controller) of the platoon. At least vehicle 1 and one other vehicle have a driver behind the steering wheel. A person behind a steering wheel may not actually be driving a vehicle. A "see-through" application is running continuously in the front vehicle to transmit video data to the other vehicles in the platoon and to enable other drivers a front view of the platoon.
  • a system (or lead vehicle for some embodiments) sends driver availability requests to each vehicle in the platoon.
  • Driver availability may be determined based on whether a driver is distracted, drowsy, or not behind the steering wheel 804.
  • Each non-lead (or other) vehicle measures or determines a driver's state 808 and responds with a driver state update 806.
  • the lead vehicle receives the update messages and stores 806 the updated information in the driver availability look-up table.
  • the updating process repeats continuously for each vehicle until a vehicle's driver or system discontinues autonomous platooning mode. The remaining platooning vehicles continue the updating process.
  • FIG. 9 is a flowchart 900 for a method of splitting a platoon and determining a new platoon leader (or supervisor).
  • FIG. 9 may be performed in addition to the process shown in FIG. 8.
  • the lead vehicle of a platoon receives an incident warning message 902.
  • this message may be received via a V2X communications channel.
  • Other vehicles or an ITS service station may detect an incident in the upcoming route segment.
  • the lead vehicle's perception system may detect an incident.
  • Receiving an incident warning message or detecting an incident by a lead vehicle may trigger interaction messages with platoon vehicle drivers to split the platoon or to change the leader (or supervisor) of the platoon.
  • the lead vehicle's in-vehicle computer system checks 904 a look-up table to determine availability of drivers (or operators) in the platoon.
  • a new platoon configuration is determined 906, which may split the platoon into two or more mini-platoons.
  • a request is sent 908 to a perspective new platoon leader.
  • the driver interacts 910 with an UMI display to respond to the request 908 about taking over control of the platoon. If the driver responds "No," the process repeats the look-up table check 904 to determine driver availability.
  • sensor data such as location of the detected object
  • video data from the front vehicle are transmitted to a new lead vehicle (based on a new platoon configuration (or mini-platoons) 914) to enable a new driver to see 916 the incident message and to assess why platoon control is being switched or reconfigured.
  • the platoon is also split 918 and a new lead vehicle and driver are assigned 920 control over a new mini- platoon. If the platoon is split 918 into three or more mini -platoons, the process shown in FIG. 9 may be repeated multiple times to assign a lead vehicle and driver to each mini-platoon.
  • FIG. 8 shows this process as a series of requests and responses regarding driver availability. The information in these messages is saved to a driver availability look-up table.
  • FIG. 9 illustrates a circumstance in which an incident warning message is received, and a system determines that the present platoon configuration is not appropriate for the incident present in the upcoming route segment.
  • a system may determine that the present platoon configuration is not appropriate for the upcoming route segment because there is, for example, a vehicle accident, a lane obstruction, a splitting of vehicle traffic into trucks and cars, or a change in the upcoming route segment to use only one lane for a direction of travel of the platoon.
  • the determination that the present platoon configuration is not appropriate for the upcoming route segment based on conditions (such as road and weather) of the upcoming route segment, the length of time the road or weather condition is calculated to last, and a lack of an available lead driver for the upcoming route segment.
  • the lead vehicle uses the driver availability look-up table as part of a process to determine a new platoon configuration.
  • a system may operate to determine a plurality of platoon configuration options that are appropriate for the upcoming route segment. Appropriateness is determined based on at least the received incident warning message. For one embodiment, a system selects a new platoon configuration based on a ranking of the appropriate platoon configuration options. The ranking, for one embodiment, is based at least on conditions (such as road and weather) of the upcoming route segment, the length of time the conditions are predicted to last, and availability of a driver for a lead driver role.
  • a system sends a request message to a perspective new platoon leader. The vehicle associated with the perspective new platoon leader sends a response message back to the lead vehicle after the perspective new platoon leader either accepts or rejects the lead driver role request. The process of FIG.
  • the lead vehicle transmits platoon configuration information to each vehicle in the platoon.
  • the platoon configuration information is transmitted to the vehicles in the platoon via messages with a mini- platoon or convoy identifier, a lead vehicle identifier, and a position number in the mini-platoon (or convoy) for the follower vehicle.
  • the platoon configuration information may be transmitted to an ITS service station.
  • the platoon vehicles perform actions, such as changing lanes to follow a new lead vehicle for a mini-platoon, in accordance with the selected platoon configuration.
  • the combined process for FIGs. 8 and 9 is performed by the lead vehicle of the present platoon configuration.
  • the present platoon configuration is the configuration of the platoon before a split or merge of the platoon was performed.
  • the combined process for FIGs. 8 and 9 is performed by an external server.
  • FIG. 9 A variation of the embodiment shown in FIG. 9 is an embodiment in which the lead vehicle of a platoon is changed but the platoon is not split into two or more mini-platoons.
  • This embodiment has a flowchart similar to FIG. 9 except that the "Split the platoon" and the "Take over the mini-platoon control" steps are not performed.
  • FIG. 10 is an illustration 1000 of an exemplary user interface 1007 for a vehicle in a platoon to request an adjustment to a platoon control parameter (or transmit control commands to the lead vehicle).
  • the lead vehicle of a platoon may receive, from another platoon vehicle, information regarding a platoon control parameter.
  • Platoon control parameters may include changing the speed 1001 up 1002 or down 1003 of each vehicle in the platoon, adjusting the lane alignment left 1005 or right 1006 by a certain amount 104 of each vehicle in the platoon, avoiding an obstacle on the left or right, or enabling or disabling stop and go mode.
  • the lead vehicle determines whether or not to change the platoon control parameter based on the information received from the other platoon vehicle regarding the platoon control parameter. If the lead vehicle changes a platoon control parameter, the lead vehicle may transmit a platoon control parameter change message to each vehicle in the platoon so that the other vehicles will make the vehicle control change corresponding to the platoon control parameter change.
  • a platoon control parameter change message may be transmitted to the lead vehicle.
  • a platoon control parameter change message may be transmitted to an ITS service station.
  • a platoon control parameter change message includes information regarding a platoon control parameter.
  • determining to change a platoon control parameter may be based on the information received regarding the platoon control parameter.
  • determining to change the platoon control parameter may also include receiving from platoon vehicles information regarding a platoon control parameter, determining which received information is the most accurate, and changing the platoon control parameter based on the most accurate received information regarding the platoon control parameter.
  • information transmitted to the lead vehicle by other vehicles may include sensor data or video data recorded by another vehicle.
  • the lead vehicle may receive environment perception system data or vehicle computer system data from other vehicles in the platoon. The lead vehicle may determine the most accurate measurement data (including sensor and video data) or the vehicle using the best object detection algorithms and use data under those scenarios.
  • a lead vehicle's computer system may send support requests to other drivers in the platoon.
  • a triggering signal that triggers a platoon reconfiguration process may come from an environment perception system of the lead vehicle or as a V2X communication message from other vehicles or an ITS service station.
  • a wide cargo load may travel towards a platoon that has both trucks and passenger cars.
  • the special transport vehicle in front of the wide cargo load warns the lead vehicle of the platoon that the wide cargo load is partly in the left lane.
  • the lead vehicle is unable to determine the best method to handle the situation.
  • One option splits the platoon into trucks and passenger cars.
  • the trucks may stop to allow the wide cargo load to pass while the passenger cars continue traveling in a new platoon.
  • Another option has the trucks take a detour while the passenger cars continue along the original route.
  • an undetected (or unknown) object may be detected and determined to be in front of the platoon.
  • the radar system of a vehicle approaching a platoon recognizes an object in front the vehicle.
  • the vehicle's lidar system does not detect any objects due to rain-induced noisy sensor readings. Therefore, the object is undetected by the vehicle.
  • the approaching vehicle sends an undetected object trigger message (or signal) to each platooning vehicle to report location of the object (which may be, for example, 400 m ahead of the platoon).
  • the lead vehicle determines that splitting the platoon is more optimal than bypassing or detouring around the difficult section.
  • the lead (or supervisor) vehicle determines that the driver of the approaching vehicle is available to take control of a mini-platoon.
  • the lead vehicle sends video data from the lead vehicle to the approaching vehicle for display on the see-through application.
  • the lead vehicle (or a system) transmits messages to split the platoon in two via messages to the other platoon vehicles.
  • FIG. 11 shows a plan view schematic 1100 for one example of vehicle movement following a change of the lead vehicle in a platoon.
  • the former lead vehicle in the first position
  • moves 1104, 1105 from the lead position 1101 in the platoon to the second 1102 or third 1103 position, respectively, in the example platoon with three vehicles.
  • the new lead vehicle moves 1106, 1107 from either the second 1102 or third 1103 position, respectively, to the lead position 1101.
  • the platoon vehicles continue moving forward and resume steady state operation.
  • a wireless transmit/receive unit may be used as a vehicle control and communications unit in embodiments described herein.
  • the network architecture shown in FIGs. 12A to 12F may be used as a communications network to transmit messages between vehicles, ITS service stations, and other external servers.
  • FIG. 12A is a diagram of an example communications system 100 in which one or more disclosed embodiments may be implemented.
  • the communications system 100 may be a multiple access system that provides content, such as voice, data, video, messaging, broadcast, and the like, to multiple wireless users.
  • the communications system 100 may enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth.
  • the communications systems 100 may employ one or more channel- access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single- carrier FDMA (SC-FDMA), and the like.
  • CDMA code division multiple access
  • TDMA time division multiple access
  • FDMA frequency division multiple access
  • OFDMA orthogonal FDMA
  • SC-FDMA single- carrier FDMA
  • the communications system 100 may include WTRUs 102a, 102b, 102c, and/or 102d (which generally or collectively may be referred to as WTRU 102), a RAN 103/104/105, a core network 106/107/109, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, though it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and/or network elements.
  • Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and/or communicate in a wireless environment.
  • the WTRUs 102a, 102b, 102c, 102d may be configured to transmit and/or receive wireless signals and may include user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, consumer electronics, and the like.
  • UE user equipment
  • PDA personal digital assistant
  • 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.
  • 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, it will be appreciated that 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.
  • the cell associated with the base station 114a may be divided into three sectors.
  • the base station 114a may include three transceivers, i.e., one for each sector of the cell.
  • the base station 114a may employ multiple- input multiple output (MIMO) technology and, therefore, may utilize multiple transceivers for each sector of the cell.
  • MIMO multiple- input multiple output
  • the base stations 114a, 1 14b may communicate with one or more of the WTRUs 102a, 102b, 102c, 102d over an air interface 115/116/117, 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 115/116/117 may be established using any suitable radio access technology (RAT).
  • RAT radio access technology
  • 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.
  • 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 115/116/117 using wideband CDMA (WCDMA).
  • WCDMA may include communication protocols such as High-Speed Packet Access (HSPA) and/or Evolved HSPA (HSPA+).
  • HSPA High-Speed Packet Access
  • HSPA+ Evolved HSPA
  • HSPA may include High-Speed Downlink Packet Access (HSDPA) and/or High-Speed Uplink Packet Access (HSUPA).
  • HSDPA High-Speed Downlink Packet Access
  • HSUPA High-Speed Uplink Packet Access
  • 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 115/116/117 using Long Term Evolution (LTE) and/or LTE- Advanced (LTE- A).
  • E-UTRA Evolved UMTS Terrestrial Radio Access
  • the base station 114a and the WTRUs 102a, 102b, 102c may implement radio technologies such as IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 IX, 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.
  • IEEE 802.16 i.e., Worldwide Interoperability for Microwave Access (WiMAX)
  • CDMA2000, CDMA2000 IX, CDMA2000 EV-DO Code Division Multiple Access 2000
  • IS-95 Interim Standard 95
  • IS-856 Interim Standard 856
  • GSM Global System for Mobile communications
  • GSM Global System for Mobile communications
  • EDGE Enhanced Data rates for GSM Evolution
  • GERAN GSM EDGERAN
  • the base station 114b in FIG. 12A may be a wireless router, Home Node B, Home eNode B, or access point, as examples, and may utilize any suitable RAT for facilitating wireless connectivity in a localized area, such as a place of business, a home, a vehicle, a campus, and the like.
  • the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN).
  • the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN).
  • WLAN wireless local area network
  • WPAN wireless personal area network
  • the base station 114b and the WTRUs 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE- A, and the like) to establish a picocell or femtocell.
  • a cellular-based RAT e.g., WCDMA, CDMA2000, GSM, LTE, LTE- A, and the like
  • the base station 114b may have a direct connection to the Internet 110.
  • the base station 114b may not be required to access the Internet 110 via the core network 106/107/109.
  • 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.
  • 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.
  • the RAN 103/104/105 and/or the core network 106/107/109 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 103/104/105 or a different RAT.
  • the core network 106/107/109 may also be in communication with another RAN (not shown) employing a GSM radio technology.
  • 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).
  • POTS plain old telephone service
  • 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.
  • TCP transmission control protocol
  • UDP user datagram protocol
  • IP 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.
  • 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, i.e., the WTRUs 102a, 102b, 102c, 102d may include multiple transceivers for communicating with different wireless networks over different wireless links.
  • the WTRU 102c shown in FIG. 12A may be configured to communicate with the base station 114a, which may employ a cellular-based radio technology, and with the base station 114b, which may employ an IEEE 802 radio technology.
  • FIG. 12B is a system diagram of an example WTRU 102.
  • the WTRU 102 may include a processor 118, a transceiver 120, a transmit/receive element 122, a speaker/microphone 124, a keypad 126, a display/touchpad 128, a non-removable memory 130, a removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and other peripherals 138.
  • the transceiver 120 may be implemented as a component of decoder logic 119.
  • the transceiver 120 and decoder logic 119 can be implemented on a single LTE or LTE-A chip.
  • the decoder logic may include a processor operative to perform instructions stored in a non-transitory computer-readable medium. As an alternative, or in addition, the decoder logic may be implemented using custom and/or programmable digital logic circuitry.
  • the WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with an embodiment.
  • 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 FIG. 12B and described herein.
  • BTS transceiver station
  • AP access point
  • eNodeB evolved home node-B
  • HeNB home evolved node-B gateway
  • proxy nodes among others, may include some or all of the elements depicted in FIG. 12B and described herein.
  • 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 1 18 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 FIG. 12B depicts the processor 118 and the transceiver 120 as separate components, it will be appreciated that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.
  • 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 115/116/117.
  • a base station e.g., the base station 114a
  • the transmit/receive element 122 may be an antenna configured to transmit and/or receive RF signals.
  • the transmit/receive element 122 may be an emitter/detector configured to transmit and/or receive IR, UV, or visible light signals, as examples.
  • the transmit/receive element 122 may be configured to transmit and receive both RF and light signals. It will be appreciated that the transmit/receive element 122 may be configured to transmit and/or receive any combination of wireless signals.
  • the WTRU 102 may include any number of transmit/receive elements 122. More specifically, the WTRU 102 may employ MTMO technology. Thus, in one embodiment, the WTRU 102 may include two or more transmit/receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 115/116/117.
  • the WTRU 102 may include two or more transmit/receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 115/116/117.
  • 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.
  • the WTRU 102 may have multi-mode capabilities.
  • 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 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.
  • 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
  • the removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like.
  • SIM subscriber identity module
  • SD secure digital
  • 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.
  • 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.
  • location information e.g., longitude and latitude
  • the WTRU 102 may receive location information over the air interface 115/116/117 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. It will be appreciated that 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.
  • 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.
  • 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
  • FIG. 12C is a system diagram of the RAN 103 and the core network 106 according to an embodiment.
  • the RAN 103 may employ a UTRA radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 1 15.
  • the RAN 103 may also be in communication with the core network 106.
  • the RAN 103 may include Node-Bs 140a, 140b, 140c, which may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 115.
  • 140b, 140c may each be associated with a particular cell (not shown) within the RAN 103.
  • RAN 103 may also include RNCs 142a, 142b. It will be appreciated that the RAN 103 may include any number of Node-Bs and RNCs while remaining consistent with an embodiment.
  • the Node-Bs 140a, 140b may be in communication with the RNC 142a. Additionally, the Node-B 140c may be in communication with the RNC 142b.
  • the Node-Bs 140a, 140b, 140c may communicate with the respective RNCs 142a, 142b via an Iub interface.
  • the RNCs 142a, 142b may be in communication with one another via an Iur interface.
  • Each of the RNCs 142a, 142b may be configured to control the respective Node-Bs 140a, 140b, 140c to which it is connected.
  • each of the RNCs 142a, 142b may be configured to carry out or support other functionality, such as outer-loop power control, load control, admission control, packet scheduling, handover control, macrodiversity, security functions, data encryption, and the like.
  • the core network 106 shown in FIG. 12C may include a media gateway (MGW) 144, a mobile switching center (MSC) 146, a serving GPRS support node (SGSN) 148, and/or a gateway GPRS support node (GGSN) 150. While each of the foregoing elements are depicted as part of the core network 106, it will be appreciated that any one of these elements may be owned and/or operated by an entity other than the core network operator.
  • MGW media gateway
  • MSC mobile switching center
  • SGSN serving GPRS support node
  • GGSN gateway GPRS support node
  • 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.
  • 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.
  • FIG. 12D is a system diagram of the RAN 104 and the core network 107 according to an embodiment.
  • the RAN 104 may employ an E-UTRA radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 1 16.
  • the RAN 104 may also be in communication with the core network 107.
  • the RAN 104 may include eNode Bs 160a, 160b, 160c, though it will be appreciated that 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.
  • the eNode Bs 160a, 160b, 160c may implement MTMO technology.
  • 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 FIG. 12D, the eNode Bs 160a, 160b, 160c may communicate with one another over an X2 interface.
  • the core network 107 shown in FIG. 12D may include a mobility management entity (MME) 162, a serving gateway 164, and a packet data network (PDN) gateway 166. While each of the foregoing elements are depicted as part of the core network 107, it will be appreciated that any one of these elements may be owned and/or operated by an entity other than the core network operator.
  • MME mobility management entity
  • PDN packet data network
  • the MME 162 may be connected to each of the eNode Bs 160a, 160b, 160c in the RAN 104 via an SI interface and may serve as a control node.
  • the MME 162 may be responsible for authenticating users of the WTRUs 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 SI 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 when downlink data is available for the WTRUs 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 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 PDN gateway 166 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 core network 107 may facilitate communications with other networks.
  • the core network 107 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 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.
  • IMS IP multimedia subsystem
  • 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.
  • FIG. 12E is a system diagram of the RAN 105 and the core network 109 according to an embodiment.
  • the RAN 105 may be an access service network (ASN) that employs IEEE 802.16 radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 117.
  • ASN access service network
  • the communication links between the different functional entities of the WTRUs 102a, 102b, 102c, the RAN 105, and the core network 109 may be defined as reference points.
  • the RAN 105 may include base stations 180a, 180b, 180c, and an ASN gateway 182, though it will be appreciated that the RAN 105 may include any number of base stations and ASN gateways while remaining consistent with an embodiment.
  • the base stations 180a, 180b, 180c may each be associated with a particular cell (not shown) in the RAN 105 and may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 117.
  • the base stations 180a, 180b, 180c may implement MTMO technology.
  • the base station 180a for example, may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 102a.
  • the base stations 180a, 180b, 180c may also provide mobility-management functions, such as handoff triggering, tunnel establishment, radio-resource management, traffic classification, quality-of- service (QoS) policy enforcement, and the like.
  • the ASN gateway 182 may serve as a traffic aggregation point and may be responsible for paging, caching of subscriber profiles, routing to the core network 109, and the like.
  • the air interface 117 between the WTRUs 102a, 102b, 102c and the RAN 105 may be defined as an Rl reference point that implements the IEEE 802.16 specification.
  • 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.
  • the RAN 105 may be connected to the core network 109.
  • the communication link between the RAN 105 and the core network 109 may defined as an R3 reference point that includes protocols for facilitating data transfer and mobility-management capabilities, as examples.
  • the core network 109 may include a mobile-IP home agent (MTP-HA) 184, an authentication, authorization, accounting (AAA) server 186, and a gateway 188. While each of the foregoing elements are depicted as part of the core network 109, it will be appreciated that any one of these elements may be owned and/or operated by an entity other than the core network operator.
  • MTP-HA mobile-IP home agent
  • AAA authentication, authorization, accounting
  • the M P-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 MTP-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.
  • 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.
  • 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.
  • the RAN 105 may be connected to other ASNs and the core network 109 may be connected to other core networks.
  • the communication link between the RAN 105 the other ASNs may be defined as an R4 reference point (not shown), which may include protocols for coordinating the mobility of the WTRUs 102a, 102b, 102c between the RAN 105 and the other ASNs.
  • the communication link between the core network 109 and the other core networks may be defined as an R5 reference point (not shown), which may include protocols for facilitating interworking between home core networks and visited core networks.
  • FIG. 12F depicts an example network entity 190 that may be used within the communication system 100 of FIG. 12A.
  • network entity 190 includes a communication interface 192, a processor 194, and non-transitory data storage 196, all of which are communicatively linked by a bus, network, or other communication path 198.
  • 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 (perhaps including multiple transceivers) for serving multiple mobile stations, UEs, or other access terminals in a coverage area.
  • wireless communication interface 192 may include the appropriate equipment and circuitry (perhaps including multiple transceivers)
  • 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 could be used.
  • data storage 196 contains program instructions 197 executable by processor 194 for carrying out various combinations of the various network-entity functions described herein.
  • the network-entity functions described herein are carried out by a network entity having a structure similar to that of network entity 190 of FIG. 12F. In some embodiments, one or more of such functions are carried out by a set of multiple network entities in combination, where each network entity has a structure similar to that of network entity 190 of
  • network entity 190 is— or at least includes— one or more of (one or more entities in) RAN 103, (one or more entities in) RAN 104, (one or more entities in) RAN 105, (one or more entities in) core network 106, (one or more entities in) core network 107, (one or more entities in) core network 109, base station 114a, base station 114b,
  • network entities and/or combinations of network entities could be used in various embodiments for carrying out the network-entity functions described herein, as the foregoing list is provided by way of example and not by way of limitation.
  • modules that carry out (i.e., perform, execute, and the like) various functions that are described herein in connection with the respective modules.
  • 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.
  • ASICs application-specific integrated circuits
  • FPGAs field programmable gate arrays
  • 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 it is noted that those instructions could take the form of or include hardware (i.e., 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, ROM, etc.
  • ROM read only memory
  • RAM random access memory
  • 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.

Abstract

L'invention concerne des systèmes et des procédés de reconfiguration de peloton de véhicules. Un procédé illustratif consiste à recevoir de chaque véhicule dans un peloton des informations concernant la disponibilité du conducteur associée au véhicule. Lors de la détermination que la présente configuration de peloton n'est pas appropriée pour un segment d'itinéraire à venir, un système sélectionne une configuration de peloton appropriée en partie en fonction de la disponibilité d'un conducteur pour mener un segment de mini-peloton quelconque qui fait partie de la reconfiguration de peloton sélectionnée. Le système transmet la configuration de peloton sélectionnée à chaque véhicule dans le peloton, de sorte que chaque véhicule fonctionne conformément à la configuration de peloton sélectionnée. Le système met à jour en continu une table de recherche de disponibilités de conducteur en utilisant des réponses à des demandes de disponibilité de conducteur envoyées à chaque véhicule. La table de recherche de disponibilités de conducteur est utilisée pour déterminer des reconfigurations de peloton.
PCT/US2017/046993 2016-08-19 2017-08-15 Procédé de changement de véhicule de tête de peloton de véhicules WO2018035145A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201662377202P 2016-08-19 2016-08-19
US62/377,202 2016-08-19

Publications (1)

Publication Number Publication Date
WO2018035145A1 true WO2018035145A1 (fr) 2018-02-22

Family

ID=59745332

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2017/046993 WO2018035145A1 (fr) 2016-08-19 2017-08-15 Procédé de changement de véhicule de tête de peloton de véhicules

Country Status (1)

Country Link
WO (1) WO2018035145A1 (fr)

Cited By (31)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10216195B2 (en) 2011-07-06 2019-02-26 Peloton Technology, Inc. Applications for using mass estimations for vehicles
US10254764B2 (en) 2016-05-31 2019-04-09 Peloton Technology, Inc. Platoon controller state machine
US10369998B2 (en) 2016-08-22 2019-08-06 Peloton Technology, Inc. Dynamic gap control for automated driving
US10474166B2 (en) 2011-07-06 2019-11-12 Peloton Technology, Inc. System and method for implementing pre-cognition braking and/or avoiding or mitigation risks among platooning vehicles
US10514706B2 (en) 2011-07-06 2019-12-24 Peloton Technology, Inc. Gap measurement for vehicle convoying
WO2019243052A1 (fr) * 2018-06-19 2019-12-26 Siemens Mobility GmbH Procédé et dispositif de surveillance et/ou de commande mutuelle de systèmes techniques autonomes
US10520581B2 (en) 2011-07-06 2019-12-31 Peloton Technology, Inc. Sensor fusion for autonomous or partially autonomous vehicle control
US10520952B1 (en) 2011-07-06 2019-12-31 Peloton Technology, Inc. Devices, systems, and methods for transmitting vehicle data
WO2020035249A1 (fr) * 2018-08-13 2020-02-20 British Telecommunications Public Limited Company Accrochage virtuel de véhicule à un convoi
EP3614355A1 (fr) * 2018-08-23 2020-02-26 Volkswagen Aktiengesellschaft Appareil, procédé et programme informatique pour des véhicules d'un groupe de véhicules
US20200133308A1 (en) * 2018-10-18 2020-04-30 Cartica Ai Ltd Vehicle to vehicle (v2v) communication less truck platooning
CN111301412A (zh) * 2018-11-26 2020-06-19 丰田自动车株式会社 队列行驶系统
CN111459149A (zh) * 2019-01-02 2020-07-28 中国移动通信有限公司研究院 一种智能车辆编队行驶方法、装置及系统
US10732645B2 (en) 2011-07-06 2020-08-04 Peloton Technology, Inc. Methods and systems for semi-autonomous vehicular convoys
US10762791B2 (en) 2018-10-29 2020-09-01 Peloton Technology, Inc. Systems and methods for managing communications between vehicles
CN111721313A (zh) * 2019-03-20 2020-09-29 现代自动车株式会社 导航系统及其路线搜索方法
WO2020221420A1 (fr) * 2019-04-29 2020-11-05 Volvo Truck Corporation Procédé destiné au changement de voie d'une pluralité de véhicules
WO2020197728A3 (fr) * 2019-03-25 2020-11-05 Micron Technology, Inc. Mécanisme de conduite en convoi reposant sur une cryptographie de gestion de flotte de véhicules autonomes
US10899323B2 (en) 2018-07-08 2021-01-26 Peloton Technology, Inc. Devices, systems, and methods for vehicle braking
US20210240203A1 (en) * 2020-01-30 2021-08-05 Hyundai Motor Company Method and Apparatus for Performing Platooning of the Moving Object
US11099579B2 (en) * 2018-05-31 2021-08-24 Nissan North America, Inc. System for determining the number of remote vehicles following a host vehicle
US11109195B2 (en) * 2017-03-31 2021-08-31 Huawei Technologies Co., Ltd. Radio system with uplink beacon transmission
EP3768554A4 (fr) * 2018-03-22 2021-11-17 KOC Universitesi Peloton autonome sécurisé assisté par communication par lumière visible
US11294396B2 (en) 2013-03-15 2022-04-05 Peloton Technology, Inc. System and method for implementing pre-cognition braking and/or avoiding or mitigation risks among platooning vehicles
US20220126841A1 (en) * 2020-10-27 2022-04-28 Hyundai Motor Company Platooning Controller Based on Driver State, System Including the Same, and Method Thereof
US11334092B2 (en) 2011-07-06 2022-05-17 Peloton Technology, Inc. Devices, systems, and methods for transmitting vehicle data
US11427196B2 (en) 2019-04-15 2022-08-30 Peloton Technology, Inc. Systems and methods for managing tractor-trailers
US11493936B2 (en) * 2019-08-27 2022-11-08 Hyundai Motor Company Platooning management device, system including the same, and method thereof
US20220415179A1 (en) * 2021-06-23 2022-12-29 Qualcomm Incorporated Sub-platoons within vehicle-to-everything technology
CN116132948A (zh) * 2023-04-04 2023-05-16 西安紫光展锐科技有限公司 车辆编队方法、装置、车辆及路侧单元
US11756424B2 (en) 2020-07-24 2023-09-12 AutoBrains Technologies Ltd. Parking assist

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090157461A1 (en) * 2007-12-12 2009-06-18 Honeywell International Inc. Vehicle deployment planning system
US8352112B2 (en) 2009-04-06 2013-01-08 GM Global Technology Operations LLC Autonomous vehicle management
US8519853B2 (en) 2008-11-05 2013-08-27 The George Washington University Unobtrusive driver drowsiness detection system and method
US20140244144A1 (en) * 2013-02-26 2014-08-28 Hyundai Motor Company Vehicle apparatus and system for controlling platoon travel and method for selecting lead vehicle
US8874301B1 (en) 2013-07-09 2014-10-28 Ford Global Technologies, Llc Autonomous vehicle with driver presence and physiological monitoring

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090157461A1 (en) * 2007-12-12 2009-06-18 Honeywell International Inc. Vehicle deployment planning system
US8519853B2 (en) 2008-11-05 2013-08-27 The George Washington University Unobtrusive driver drowsiness detection system and method
US8352112B2 (en) 2009-04-06 2013-01-08 GM Global Technology Operations LLC Autonomous vehicle management
US20140244144A1 (en) * 2013-02-26 2014-08-28 Hyundai Motor Company Vehicle apparatus and system for controlling platoon travel and method for selecting lead vehicle
US8874301B1 (en) 2013-07-09 2014-10-28 Ford Global Technologies, Llc Autonomous vehicle with driver presence and physiological monitoring

Non-Patent Citations (5)

* Cited by examiner, † Cited by third party
Title
"Intelligent Transport System (ITS): Cooperative Adaptive Cruise Control (CACC): Pre-Standardization Study", ETSI TECHNICAL REPORT, vol. 103, 2016, pages 299
"Intelligent Transport Systems (ITS): Vehicular Communications: Basic Set of Applications: Local Dynamic Map (LDM): Rationale for and Guidance on Standardization", ETSI TECHNICAL REPORT, vol. 102, 2011, pages 863
ETSI TECHNICAL REPORT, vol. 102, pages 863
GOMES F VIEIRA; M FERREIRA: "See-Through System. From Implementation to Test-Drive", IEEE VEHICULAR NETWORKING CONFERENCE (VNC, 14 November 2012 (2012-11-14)
M. KUTILA; M. JOKELA; G. MARKKULA; M. R. RUE: "Driver Distraction Detection with a Camera Vision System", PROCEEDINGS OF THE IEEE INTERNATIONAL CONFERENCE ON IMAGE PROCESSING (ICIP, vol. VI, 16 September 2007 (2007-09-16), pages 201 - 204

Cited By (41)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10216195B2 (en) 2011-07-06 2019-02-26 Peloton Technology, Inc. Applications for using mass estimations for vehicles
US10520581B2 (en) 2011-07-06 2019-12-31 Peloton Technology, Inc. Sensor fusion for autonomous or partially autonomous vehicle control
US10474166B2 (en) 2011-07-06 2019-11-12 Peloton Technology, Inc. System and method for implementing pre-cognition braking and/or avoiding or mitigation risks among platooning vehicles
US11334092B2 (en) 2011-07-06 2022-05-17 Peloton Technology, Inc. Devices, systems, and methods for transmitting vehicle data
US11360485B2 (en) 2011-07-06 2022-06-14 Peloton Technology, Inc. Gap measurement for vehicle convoying
US10514706B2 (en) 2011-07-06 2019-12-24 Peloton Technology, Inc. Gap measurement for vehicle convoying
US10234871B2 (en) 2011-07-06 2019-03-19 Peloton Technology, Inc. Distributed safety monitors for automated vehicles
US10732645B2 (en) 2011-07-06 2020-08-04 Peloton Technology, Inc. Methods and systems for semi-autonomous vehicular convoys
US10520952B1 (en) 2011-07-06 2019-12-31 Peloton Technology, Inc. Devices, systems, and methods for transmitting vehicle data
US11294396B2 (en) 2013-03-15 2022-04-05 Peloton Technology, Inc. System and method for implementing pre-cognition braking and/or avoiding or mitigation risks among platooning vehicles
US10254764B2 (en) 2016-05-31 2019-04-09 Peloton Technology, Inc. Platoon controller state machine
US10906544B2 (en) 2016-08-22 2021-02-02 Peloton Technology, Inc. Dynamic gap control for automated driving
US10921822B2 (en) 2016-08-22 2021-02-16 Peloton Technology, Inc. Automated vehicle control system architecture
US10369998B2 (en) 2016-08-22 2019-08-06 Peloton Technology, Inc. Dynamic gap control for automated driving
US11109195B2 (en) * 2017-03-31 2021-08-31 Huawei Technologies Co., Ltd. Radio system with uplink beacon transmission
EP3768554A4 (fr) * 2018-03-22 2021-11-17 KOC Universitesi Peloton autonome sécurisé assisté par communication par lumière visible
US11099579B2 (en) * 2018-05-31 2021-08-24 Nissan North America, Inc. System for determining the number of remote vehicles following a host vehicle
WO2019243052A1 (fr) * 2018-06-19 2019-12-26 Siemens Mobility GmbH Procédé et dispositif de surveillance et/ou de commande mutuelle de systèmes techniques autonomes
US10899323B2 (en) 2018-07-08 2021-01-26 Peloton Technology, Inc. Devices, systems, and methods for vehicle braking
WO2020035249A1 (fr) * 2018-08-13 2020-02-20 British Telecommunications Public Limited Company Accrochage virtuel de véhicule à un convoi
CN112585651A (zh) * 2018-08-13 2021-03-30 英国电讯有限公司 车辆编队
EP3614355A1 (fr) * 2018-08-23 2020-02-26 Volkswagen Aktiengesellschaft Appareil, procédé et programme informatique pour des véhicules d'un groupe de véhicules
US20200133308A1 (en) * 2018-10-18 2020-04-30 Cartica Ai Ltd Vehicle to vehicle (v2v) communication less truck platooning
US10762791B2 (en) 2018-10-29 2020-09-01 Peloton Technology, Inc. Systems and methods for managing communications between vehicles
US11341856B2 (en) 2018-10-29 2022-05-24 Peloton Technology, Inc. Systems and methods for managing communications between vehicles
CN111301412A (zh) * 2018-11-26 2020-06-19 丰田自动车株式会社 队列行驶系统
CN111459149B (zh) * 2019-01-02 2023-10-27 中国移动通信有限公司研究院 一种智能车辆编队行驶方法、装置及系统
CN111459149A (zh) * 2019-01-02 2020-07-28 中国移动通信有限公司研究院 一种智能车辆编队行驶方法、装置及系统
CN111721313A (zh) * 2019-03-20 2020-09-29 现代自动车株式会社 导航系统及其路线搜索方法
US11049402B2 (en) 2019-03-25 2021-06-29 Micron Technology, Inc. Cryptography-based platooning mechanism for autonomous vehicle fleet management
EP3948471A4 (fr) * 2019-03-25 2023-01-04 Micron Technology, Inc. Mécanisme de conduite en convoi reposant sur une cryptographie de gestion de flotte de véhicules autonomes
US20210319702A1 (en) * 2019-03-25 2021-10-14 Micron Technology, Inc. Cryptography-Based Platooning Mechanism for Autonomous Vehicle Fleet Management
WO2020197728A3 (fr) * 2019-03-25 2020-11-05 Micron Technology, Inc. Mécanisme de conduite en convoi reposant sur une cryptographie de gestion de flotte de véhicules autonomes
US11427196B2 (en) 2019-04-15 2022-08-30 Peloton Technology, Inc. Systems and methods for managing tractor-trailers
WO2020221420A1 (fr) * 2019-04-29 2020-11-05 Volvo Truck Corporation Procédé destiné au changement de voie d'une pluralité de véhicules
US11493936B2 (en) * 2019-08-27 2022-11-08 Hyundai Motor Company Platooning management device, system including the same, and method thereof
US20210240203A1 (en) * 2020-01-30 2021-08-05 Hyundai Motor Company Method and Apparatus for Performing Platooning of the Moving Object
US11756424B2 (en) 2020-07-24 2023-09-12 AutoBrains Technologies Ltd. Parking assist
US20220126841A1 (en) * 2020-10-27 2022-04-28 Hyundai Motor Company Platooning Controller Based on Driver State, System Including the Same, and Method Thereof
US20220415179A1 (en) * 2021-06-23 2022-12-29 Qualcomm Incorporated Sub-platoons within vehicle-to-everything technology
CN116132948A (zh) * 2023-04-04 2023-05-16 西安紫光展锐科技有限公司 车辆编队方法、装置、车辆及路侧单元

Similar Documents

Publication Publication Date Title
WO2018035145A1 (fr) Procédé de changement de véhicule de tête de peloton de véhicules
EP3552071B1 (fr) Système et procédé de routage et de réorganisation d'un peloton de véhicules dans une ville intelligente
US20230013993A1 (en) Method and apparatus for controlling communication between devices in a network
US11373525B2 (en) Dynamic edge network management of vehicular traffic
CN107950039B (zh) 用于提供在车辆之间的传输参数的设备、方法和计算机程序
US20220116814A1 (en) Meeting strict qos requirements through network control of device route and location
US11516620B2 (en) Vehicle to everything dynamic geofence
US10467893B1 (en) Connected vehicle technology to assist visually impaired
US11743694B2 (en) Vehicle to everything object exchange system
JP6942413B2 (ja) 通信装置、通信システム、及び通信制御方法
US20210168664A1 (en) Communication device, user terminal, communication system, notification method, and program for handover communications
EP3912326A1 (fr) Communication de véhicule à véhicule et de véhicule à réseau
Rammohan Revolutionizing Intelligent Transportation Systems with Cellular Vehicle-to-Everything (C-V2X) technology: Current trends, use cases, emerging technologies, standardization bodies, industry analytics and future directions
EP4062387A1 (fr) Procédés de communication pour la gestion d'intersection de trafic
CN115968533A (zh) 管理无人飞行系统的c2通信模式
GB2592277A (en) Method and network
Narasimha et al. Connected Automobiles
US20220345860A1 (en) Road side unit for v2x service
JP7268138B2 (ja) 通信装置、ユーザ端末、通信システム及びその制御方法並びにプログラム
US20220408214A1 (en) Method for v2x service, and server using same
WO2023215365A1 (fr) Détection préemptive de véhicule à piéton
CN117915292A (zh) 电子设备、通信方法和存储介质
CA3230485A1 (fr) Configuration d'une zone a hauts risques
GB2574887A (en) Network and control thereof

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 17758976

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 17758976

Country of ref document: EP

Kind code of ref document: A1