WO2017160562A1 - Procédés et systèmes pour surveiller des intersections avec des véhicules connectés à l'arrêt - Google Patents

Procédés et systèmes pour surveiller des intersections avec des véhicules connectés à l'arrêt Download PDF

Info

Publication number
WO2017160562A1
WO2017160562A1 PCT/US2017/021417 US2017021417W WO2017160562A1 WO 2017160562 A1 WO2017160562 A1 WO 2017160562A1 US 2017021417 W US2017021417 W US 2017021417W WO 2017160562 A1 WO2017160562 A1 WO 2017160562A1
Authority
WO
WIPO (PCT)
Prior art keywords
vehicle
ltm
parking
monitoring
location
Prior art date
Application number
PCT/US2017/021417
Other languages
English (en)
Inventor
Mikko Tarkiainen
Matti Kutila
Pertti PEUSSA
Ari Virtanen
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 WO2017160562A1 publication Critical patent/WO2017160562A1/fr

Links

Classifications

    • G—PHYSICS
    • G08—SIGNALLING
    • G08G—TRAFFIC CONTROL SYSTEMS
    • G08G1/00—Traffic control systems for road vehicles
    • G08G1/14—Traffic control systems for road vehicles indicating individual free spaces in parking areas
    • G08G1/141—Traffic control systems for road vehicles indicating individual free spaces in parking areas with means giving the indication of available parking spaces
    • G08G1/143—Traffic control systems for road vehicles indicating individual free spaces in parking areas with means giving the indication of available parking spaces inside the vehicles
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/02—Reservations, e.g. for tickets, services or events
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q50/00—Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
    • G06Q50/40—Business processes related to the transportation industry
    • G—PHYSICS
    • G08—SIGNALLING
    • G08G—TRAFFIC CONTROL SYSTEMS
    • G08G1/00—Traffic control systems for road vehicles
    • G08G1/01—Detecting movement of traffic to be counted or controlled
    • G08G1/0104—Measuring and analyzing of parameters relative to traffic conditions
    • G08G1/0108—Measuring and analyzing of parameters relative to traffic conditions based on the source of data
    • G08G1/0112—Measuring and analyzing of parameters relative to traffic conditions based on the source of data from the vehicle, e.g. floating car data [FCD]
    • G—PHYSICS
    • G08—SIGNALLING
    • G08G—TRAFFIC CONTROL SYSTEMS
    • G08G1/00—Traffic control systems for road vehicles
    • G08G1/01—Detecting movement of traffic to be counted or controlled
    • G08G1/0104—Measuring and analyzing of parameters relative to traffic conditions
    • G08G1/0125—Traffic data processing
    • G08G1/0133—Traffic data processing for classifying traffic situation
    • G—PHYSICS
    • G08—SIGNALLING
    • G08G—TRAFFIC CONTROL SYSTEMS
    • G08G1/00—Traffic control systems for road vehicles
    • G08G1/01—Detecting movement of traffic to be counted or controlled
    • G08G1/0104—Measuring and analyzing of parameters relative to traffic conditions
    • G08G1/0137—Measuring and analyzing of parameters relative to traffic conditions for specific applications
    • G08G1/0141—Measuring and analyzing of parameters relative to traffic conditions for specific applications for traffic information dissemination
    • G—PHYSICS
    • G08—SIGNALLING
    • G08G—TRAFFIC CONTROL SYSTEMS
    • G08G1/00—Traffic control systems for road vehicles
    • G08G1/09—Arrangements for giving variable traffic instructions
    • G08G1/0962—Arrangements for giving variable traffic instructions having an indicator mounted inside the vehicle, e.g. giving voice messages
    • G08G1/0967—Systems involving transmission of highway information, e.g. weather, speed limits
    • G08G1/096708—Systems involving transmission of highway information, e.g. weather, speed limits where the received information might be used to generate an automatic action on the vehicle control
    • G08G1/096716—Systems involving transmission of highway information, e.g. weather, speed limits where the received information might be used to generate an automatic action on the vehicle control where the received information does not generate an automatic action on the vehicle control
    • G—PHYSICS
    • G08—SIGNALLING
    • G08G—TRAFFIC CONTROL SYSTEMS
    • G08G1/00—Traffic control systems for road vehicles
    • G08G1/09—Arrangements for giving variable traffic instructions
    • G08G1/0962—Arrangements for giving variable traffic instructions having an indicator mounted inside the vehicle, e.g. giving voice messages
    • G08G1/0967—Systems involving transmission of highway information, e.g. weather, speed limits
    • G08G1/096733—Systems involving transmission of highway information, e.g. weather, speed limits where a selection of the information might take place
    • G08G1/096741—Systems involving transmission of highway information, e.g. weather, speed limits where a selection of the information might take place where the source of the transmitted information selects which information to transmit to each vehicle
    • G—PHYSICS
    • G08—SIGNALLING
    • G08G—TRAFFIC CONTROL SYSTEMS
    • G08G1/00—Traffic control systems for road vehicles
    • G08G1/09—Arrangements for giving variable traffic instructions
    • G08G1/0962—Arrangements for giving variable traffic instructions having an indicator mounted inside the vehicle, e.g. giving voice messages
    • G08G1/0967—Systems involving transmission of highway information, e.g. weather, speed limits
    • G08G1/096766—Systems involving transmission of highway information, e.g. weather, speed limits where the system is characterised by the origin of the information transmission
    • G08G1/096775—Systems involving transmission of highway information, e.g. weather, speed limits where the system is characterised by the origin of the information transmission where the origin of the information is a central station
    • G—PHYSICS
    • G08—SIGNALLING
    • G08G—TRAFFIC CONTROL SYSTEMS
    • G08G1/00—Traffic control systems for road vehicles
    • G08G1/09—Arrangements for giving variable traffic instructions
    • G08G1/0962—Arrangements for giving variable traffic instructions having an indicator mounted inside the vehicle, e.g. giving voice messages
    • G08G1/0967—Systems involving transmission of highway information, e.g. weather, speed limits
    • G08G1/096766—Systems involving transmission of highway information, e.g. weather, speed limits where the system is characterised by the origin of the information transmission
    • G08G1/096791—Systems involving transmission of highway information, e.g. weather, speed limits where the system is characterised by the origin of the information transmission where the origin of the information is another vehicle

Definitions

  • This disclosure relates to systems and methods for sensor and communication systems of connected vehicles.
  • Traffic monitoring and measuring has been mainly done using roadside equipment.
  • Existing traffic monitoring and detection systems typically utilize various sensors of such roadside equipment to gather traffic or incident data.
  • VRU Vulnerable Road Users
  • V2X vehicle-to-everything
  • vehicles could share information about the objects they have detected via vehicle-to- vehicle (V2V) communication, or intersections could be installed with various detectors and vehicle-to-infrastructure (V2I) communication roadside units (RSU), which would detect and communicate warnings to approaching vehicles and other road users.
  • V2V vehicle-to- vehicle
  • V2I vehicle-to-infrastructure
  • RSU roadside units
  • the disclosed systems and methods improve the ability to monitor intersections and other specific road/street locations (e.g., in dangerous intersections without traffic lights, busy intersections, etc.) by utilizing sensory, computing, and communication systems of parked connected vehicles.
  • the locations may be in urban areas.
  • the parked connected vehicles may be used within a "Local Traffic Monitoring service" or LTM for traffic monitoring and behavior tracking of road users.
  • a central backend system of the service may select where and when vehicle based monitoring is needed and may guide LTM service capable vehicles to park at predefined monitoring locations (e.g., on-street parking places looking towards an intersection).
  • An LTM application in the vehicles may provide vehicle sensor data (including detected objects and events) to the backend system, which combines all data from different vehicles and implements the traffic monitoring service.
  • In-vehicle sensing technologies computing power (including advanced algorithms) and communication capabilities (especially cellular connectivity) of vehicles are developing fast.
  • Autonomous and semi-automated vehicles are coming to the market with state-of-the art environment perception, computing and communication systems.
  • These vehicles are also in many cases electric or hybrid (or e.g. hydrogen) vehicles where in-vehicle electric energy storage is very large. This fact enables in-vehicle sensing, computing and communication system usage while such vehicles are parked.
  • Computing power requirements for stationary (parked) vehicle environment sensing are not as high as for vehicles moving at higher speeds.
  • Traffic monitoring systems based on parked connected vehicles can be more widely utilized and have extended coverage area compared to standalone monitoring systems that do not incorporate connected vehicles providing any local traffic monitoring service. This can increase the safety of all road users. Such systems are possible because of the availability of accurate and versatile data from the modern sensor systems of equipped vehicles.
  • cities can save substantial resources, as the need to install roadside units is reduced. This is because the disclosed systems can reduce installation, maintenance or equipment updating costs for cities.
  • the disclosed systems can permit traffic monitoring to be flexibly changed to areas where and when it is needed, e.g., near schools when the school day is starting or ending, for example with autonomous vehicles which can be moved between monitoring locations as needed.
  • the disclosed systems can also present new opportunities for connected vehicles to be fully utilized while they are parked, creating potential new business cases for autonomous vehicle owners, such as selling traffic monitoring data where it is needed when the vehicle is not used by the owner.
  • the disclosed LTM service is very scalable and can utilize various types of in-vehicle sensors of connected vehicles ranging from a simple camera view of a manually driven vehicle to autonomous vehicles with highly advanced sensors, sensor fusion, object and event detection, and V2X communication systems.
  • FIG. 1 illustrates an exemplary embodiment of a general architecture for an LTM service and devices.
  • FIG. 2 illustrates an exemplary embodiment of a process for using an LTM service with an autonomous vehicle.
  • FIG. 3 illustrates an exemplary embodiment of a process for using an LTM service with a manually driven vehicle.
  • FIG. 4 illustrates an exemplary embodiment of a user interface (or human-machine interface, "UMI") for the LTM application providing information about available LTM-parking to a user.
  • UMI human-machine interface
  • FIG. 5 illustrates an exemplary scenario of an implementation of the LTM service, where a vehicle is parked and provides LTM service for an intersection.
  • FIG. 6 illustrates an exemplary scenario of an implementation of the LTM service, where a vehicle is parked and provides LTM service for a crosswalk near a school.
  • FIG. 7 illustrates an exemplary wireless transmit/receive unit (WTRU) that may be employed as a communication module in some embodiments.
  • WTRU wireless transmit/receive unit
  • FIG. 8 illustrates an exemplary network entity that may be employed in some embodiments.
  • modules that carry out (e.g., 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.
  • V2X communication can be utilized only if there are multiple vehicles at a specific location (e.g., an intersection) at the same time or infrastructure equipment is installed.
  • the penetration rate of V2X-capable vehicles will increase slowly, and it will take years before a significant number of vehicles on the road are equipped.
  • the real safety benefits of V2X only can be realized when compatible equipment makes up a sufficiently large part of the installed vehicle and/or infrastructure base.
  • FIG. 1 An exemplary embodiment of a general architecture of the present disclosure is illustrated in FIG. 1, showing the interplay between three main actors: a first vehicle, a backend for a local traffic monitoring (“LTM”) service, and other nearby vehicles and/or road users which receive messages from the LTM service, such as via the first vehicle's local communication.
  • LTM local traffic monitoring
  • the first vehicle can be an autonomous or manually driven vehicle.
  • the vehicle comprises: an in-vehicle terminal, and at least one vehicle sensor.
  • the in-vehicle terminal may further comprise an LTM Application, which may be capable of: searching for suitable LTM parking places for the vehicle; supporting parking of the vehicle according to received instructions, (e.g., direction/heading of the vehicle); monitoring the target area while parked; communicating with the backend service and locally with other vehicles and road users (e.g., to deliver warnings); and/or the like.
  • the in-vehicle terminal may further comprise short-range (e.g., V2X or DSRC, and/or the like) and wide area wireless communication (e.g., cellular) systems.
  • short-range e.g., V2X or DSRC, and/or the like
  • wide area wireless communication e.g., cellular
  • one or more of the communication systems may comprise a WTRU, as more fully disclosed below.
  • the in-vehicle terminal may comprise a digital map database and locations of LTM parking places (e.g., parking place locations can be received from the backend service).
  • the in-vehicle terminal may comprise a user interface (also called a human-machine interface, "HMI") for guiding a manually driven car to an LTM parking place and/or supporting a driver while parking.
  • HMI human-machine interface
  • a digital map database and locations of LTM parking places may be part of a remote cloud server, accessible to the in-vehicle terminal.
  • the in-vehicle terminal may comprise a wireless transmit/receive unit, as further discussed below.
  • the vehicle further comprises at least one vehicle sensor (or in-vehicle sensor).
  • the at least one sensor is in communication with the in-vehicle terminal, providing vehicle sensor data access to the terminal.
  • a backend for LTM service comprises functionality including, but not limited to: a monitoring area selection, a parking place allocation, maintaining a vehicle database, and the traffic monitoring service.
  • a monitoring area selection module may maintain a list of target monitoring areas (e.g., monitoring locations), and also maintain a list of LTM parking places.
  • a plurality of LTM parking places may be associated with a given monitoring area or monitoring location.
  • the list of target monitoring areas or monitoring locations may include areas such as dangerous intersections, pedestrian crossings without traffic lights or other roadside equipment, as well as times when monitoring is needed (or not needed) in each location.
  • the list of LTM parking places may include data indicating the directions of target monitoring and preferred vehicle sensory categories which are suitable for monitoring from each LTM parking place.
  • a parking place allocation module of the backend may function to efficiently manage distributing LTM parking places to available vehicles.
  • the module may search from a vehicle database API the vehicle sensor category for the current vehicle.
  • the module may, in some embodiments, search from a city parking operator API which of the LTM parking places suitable for this vehicle are available, if any.
  • the module may further allocate a suitable parking place for the vehicle, based on the vehicle sensor category, location and availability of the vehicle, and/or the like. After allocation, the module may reserve the parking place from the city parking operator API.
  • the module may optionally further inform other systems, such as a police system API or the like, about the allocation of the LTM parking place for the vehicle (such as with an identification, e.g., vehicle register number, license plate, etc.).
  • a vehicle database module may include information about each vehicle which is registered to the LTM service. Such information may include, but is not limited to a vehicle identification (e.g., Vehicle Identification Number, or VIN, license plate, etc.), as well as a vehicle sensor category within the LTM service.
  • vehicle identification e.g., Vehicle Identification Number, or VIN, license plate, etc.
  • vehicle sensor category within the LTM service.
  • the combined information about each registered vehicle may indicate the available vehicle sensor types, their ranges, field of view, communication capabilities, and/or the like.
  • sensor types of in-vehicle sensors include, but are not limited to, radar, LiDAR, optical sensors, cameras, imaging systems, temperature sensors, ultrasonic sensors, GPS systems, and/or the like.
  • the information may further indicate the detection and object classification or tracking capabilities of the vehicle, such as detecting and/or classifying pedestrians, bicyclists, cars and other vehicles, animals, debris, and/or the like.
  • the vehicle identification may further indicate any detection restrictions of the vehicle or the vehicle's sensors, such as weather related restrictions, and/or the like.
  • at least one in- vehicle sensor of a connected vehicle may be described by information regarding at least one of a sensor type; a sensor field of view; and a sensor range.
  • the vehicle database module may interact with the monitoring area selection module to efficiently allocate vehicles to appropriate LTM parking places.
  • a traffic monitoring service module may serve to collect real-time data and analyze that data. Collected real-time data may comprise real-time data from all vehicles parked in LTM parking places, a subset of all vehicles parked in LTM parking places, data from third party sources
  • the module may analyze the real-time data to perform functions such as, but not limited to, detecting events, anomalies, accidents, and/or the like, as well as estimating potentially dangerous situations.
  • the analysis may be used to provide warnings to other vehicles and road users approaching a dangerous situation in a monitored area via the LTM vehicle application and local communication (e.g., V2X, etc.).
  • the analysis may also provide information about traffic disruptions for a Traffic Management API.
  • the backend may comprise a wireless transmit/receive unit, as further discussed below.
  • Other vehicles and road users may receive messages from the LTM service via the first vehicle's local communication (when nearby). In some embodiments, these messages to the other vehicles or road users may be communicated from the LTM service instead of being communicated directly from the first vehicle.
  • FIG. 2 An exemplary process for an autonomous vehicle using the LTM service is illustrated in FIG. 2.
  • LTM parking places have been established (e.g., marked, reserved, etc.) where there is need to monitor with mobile units a specific street section, an intersection, and/or the like.
  • LTM parking places can be the first on-street parking places towards the target area, or the like.
  • a plurality of LTM parking places may be associated with a given monitoring location. The monitoring needs and monitoring times (e.g., in the morning when children will be crossing a dangerous street) are analyzed for these specific street sections and locations to identify areas where monitoring would be beneficial.
  • the locations and sensing directions of reserved LTM parking places are analyzed and classified according to typical vehicle sensor systems (including sensor types; sensor ranges; fields-of-view; object detection, classification, and tracking capabilities; etc.). These results have been pulled together to make a plan of how, where, when, and which type of LTM- capable vehicles should be parked to provide needed monitoring data.
  • This static information is stored in the LTM parking database.
  • connected vehicles which are capable of providing LTM services, are registered into the LTM service backend.
  • the vehicle sensor specifications including sensor types; sensor ranges; fields-of-view; communication capabilities; object detection, classification, and tracking capabilities; etc.
  • in-vehicle sensor specifications will be used to classify vehicles to LTM service categories.
  • the LTM application may be started automatically, such as when the autonomous vehicle is available for LTM service (possibly for several hours) and searching for a parking place. In some embodiments, the activation may only occur if the autonomous vehicle will be available for a threshold length of time.
  • the LTM application may request available LTM parking locations from the LTM backend service (210). Such a parking query request may include, but is not limited to, the vehicle identification (ID), the current location of the vehicle, availability (time, e.g., 6 hours, etc.) for LTM monitoring service, range limitations, and/or the like.
  • Availability time may come, for example, from a reservation schedule of the autonomous vehicle - such as factoring in the time before the next reservation or scheduled drive.
  • the LTM backend service may perform steps to allocate and direct the vehicle to a particular LTM parking place. These steps may include, but are not limited to: getting the vehicle sensor system category from the vehicle database (215); getting available LTM parking places from the parking operator API (220); performing parking place allocation for the requesting vehicle based on the vehicle sensor category, vehicle availability and available LTM parking places, and/or the like (225); making a reservation of the allocated LTM parking place for the vehicle (such as identified by the vehicle ID, etc.); replying from the LTM backend to the LTM terminal of the vehicle with LTM parking bay reservation information (230), including location (e.g., coordinates of the parking place), a primary sensing direction (e.g., the heading of the vehicle after it is parked), and/or the like.
  • the LTM backend service may offer an incentive to the vehicle operator to extend the time of the vehicle's availability. For example, if the system determines that it would be beneficial to assign a car with certain sensors to a particular spot during a particular period, but that period is longer than that for which a vehicle indicates availability, the system may offer an incentive to the user to park the vehicle at the spot for the longer period of time.
  • incentives may include, for example, a parking credit or discount or other form of compensation.
  • the backend service may also decline a parking query request. For instance, there could be no available LTM parking place in need of the particular sensors equipped on the vehicle. Alternatively, all LTM parking places within a threshold range of the vehicle could be in use. In another embodiment, the request could be denied because the vehicle will be available an insufficient period of time for the available LTM parking places.
  • the autonomous vehicle then drives to the location of the allocated parking place and initiates parking, such as between steps 230 and 235.
  • the LTM application may send the controller of the autonomous vehicle a command to start automated parking maneuvers using the target heading of the vehicle (235), in order to park the vehicle in an optimal way for sensor monitoring.
  • the vehicle may verify to the LTM service that the parking place is available and that the line of sight to the target area is free.
  • the vehicle and/or LTM service may request and/or allocate another parking location, and further the vehicle and/or LTM service may report the detected obstruction to a relevant third party (e.g., police or towing service for illegally parked vehicle, city services for tree limbs or some other debris, and/or the like).
  • a relevant third party e.g., police or towing service for illegally parked vehicle, city services for tree limbs or some other debris, and/or the like.
  • the LTM application may request real-time data from the in-vehicle sensors (240).
  • the vehicle may get sensor data (245), and respond (250) with real-time vehicle sensor data, a list of detected objects and events, and/or the like.
  • the response information may depend on the available vehicle sensors.
  • the LTM application may send the vehicle data to the LTM backend service for analysis (255).
  • the data may be sent by a cellular connection.
  • the data may be sent by a WTRU, as set forth more fully below.
  • transmission of the vehicle data e.g., monitoring of the target area
  • the LTM backend may collect data from any or all registered and allocated vehicles which are monitoring the target area, and performs an analysis on the collected data (260). If there is a need to warn road users for any dangerous situation, the LTM service may send a warning message to LTM applications (265). Such a message may include, but is not limited to, information about the warning type, target or list of receivers, and/or the like.
  • the LTM application in the vehicle may distribute (e.g., via V2X communication, WTRU, etc.) the warning message to other road users (270), which may show the warning (275) to such users if needed and/or possible.
  • the LTM backend service may request that autonomous cars change to another monitoring location by sending a new LTM parking reservation message to the vehicle.
  • the vehicle may cease sending the vehicle sensor data and drive to the new location, prior to again parking and receiving a request to initiate data transmission.
  • the LTM backend service may, in some embodiments, request for autonomous cars to stop the monitoring.
  • the LTM application in the vehicle may stop the monitoring, e.g., if the autonomous vehicle is requested for other service and it needs to leave.
  • the autonomous vehicle upon receiving a request for other service, the autonomous vehicle may indicate such a requirement to the LTM backend, and continue data transmission until a replacement vehicle can be allocated and/or arrive at the location.
  • FIG. 3 An exemplary process for a manually driven vehicle using the LTM service is illustrated in FIG. 3.
  • the backend service will only initiate monitoring when additional data is needed.
  • the example of FIG. 3 may be implemented in conditions of preregi strati on and the like that are described with respect to FIG. 2.
  • the LTM application is started by the driver of the vehicle (305), such as while searching for an LTM parking space, as the user knows she will be parked for a particular length of time.
  • the LTM application may be started before the user begins driving, permitting the user to input a destination location around which the backend service may find LTM parking places.
  • the user may input a distance around the destination location within which the LTM parking place must be found.
  • the application may be activated and perform an allocation for a future time (e.g., "reserve" an LTM parking place for a future time, such as later in the day or on a future date).
  • the LTM application may request available LTM parking locations from the LTM backend service (310).
  • a parking query request may include, but is not limited to, the vehicle identification (ID), the current location of the vehicle, availability (time, e.g., 6 hours, etc.) for LTM monitoring service, maximum range from current or user defined location (e.g., maximum distance from the destination the user is willing to park), and/or the like.
  • Availability time may come, for example, from a user input.
  • the LTM backend service may perform the steps necessary to allocate and direct the vehicle to a particular LTM parking place. These steps may include, but are not limited to: getting the vehicle sensor system category from the vehicle database (315); getting available LTM parking places from the parking operator API (320); performing parking place allocation for the requesting vehicle based on the vehicle sensor category, vehicle availability, and available LTM parking places, and/or the like (325); making a reservation of the allocated LTM parking place for the vehicle (such as identified by the vehicle ID, etc.); replying from the LTM backend to the LTM terminal of the vehicle with LTM parking bay reservation information (330), including location (e.g., coordinates of the parking place), a primary sensing direction (e.g., the heading of the vehicle after it is parked), and/or the like.
  • LTM parking bay reservation information 330
  • the backend service may also decline a parking query request. For instance, there could be no available LTM parking place in need of the particular sensors equipped on the vehicle. Alternatively, all LTM parking places within a threshold range of the vehicle could be in use. In another embodiment, the request could be denied because the vehicle will be available an insufficient period of time for the available LTM parking places.
  • the LTM application of the vehicle may display the allocated LTM parking place and related information to the user, such as through a human- machine interface ("HMI") (335).
  • HMI human- machine interface
  • the user may be prompted to confirm the allocated parking place.
  • a reservation confirmation message e.g., a Reservation OK message
  • the HMI may display the allocated parking place to the user, but not prompt the user for a confirmation (e.g., the spot is assigned, not an option, to the driver).
  • a user generally then drives to the location of the allocated parking place and begins parking the vehicle (such as between steps 345 and 350).
  • the HMI may show the position of the parking vehicle compared to optimal sensor coverage for the target area (e.g., intersection, crossing, etc.) (350).
  • the HMI may display an optimal sensor coverage parking position on the display and overlay a current sensor coverage based on the current position of the vehicle.
  • the user may in real-time be able to park in an ideal or close to ideal position relative to the optimal coverage position. Overall, the user is able to park the vehicle with the best possible view towards the monitoring area (such view previously established by the backend service).
  • the HMI and/or the LMT application may prompt the user to reposition the vehicle until a maximum threshold deviation from optimal sensor coverage is achieved.
  • the LMT service may further revoke the user's parking allocation for deviance too large (e.g., above the threshold deviation, or above a maximum permitted threshold prior to revocation).
  • the LTM application, vehicle, and/or the user may verify to the LTM service that the parking place is available and that the line of sight to the target area is free.
  • the user (or vehicle) and/or LTM service may request and/or allocate another parking location, and further the user (or vehicle) and/or LTM service may report the detected obstruction to a relevant third party (e.g., police or towing service for illegally parked vehicle, city services for tree limbs or some other debris, and/or the like).
  • a relevant third party e.g., police or towing service for illegally parked vehicle, city services for tree limbs or some other debris, and/or the like.
  • the LTM may be ready to activate.
  • a message may be sent to the LTM backend service that this vehicle (indicated such as by the vehicle ID, or other information) is now parked at the allocated LTM-parking bay and it is ready to start monitoring when requested (355).
  • the message may further indicate the actual sensor coverage of the vehicle, such as if there is a material deviation from the optimal sensor coverage.
  • the backend service could utilize such information in future analysis, such as whether to allocate another vehicle to an LTM parking place with overlapping coverage to the current vehicle.
  • the LTM backend service may perform a check on the available data from this or nearby monitoring areas (e.g., data from other LTM vehicles, traffic services, etc.) (360). In some embodiments, the LTM backend service may determine a need for additional data for the monitoring area. In such embodiments, the LTM backend service may send a message to the vehicle and/or the LTM application to start the monitoring service or otherwise collecting data from the vehicle's sensor(s) (365). Optionally, the message may indicate one or more specific categories of sensory data that is requested from this vehicle. For example, the backend service could request one or more of a video feed, object detection, object identification, and/or the like.
  • the local LTM application may request real-time data from the in-vehicle sensors (370).
  • the vehicle may get sensor data (375), and there may be a vehicle data reply with the requested real-time vehicle sensor data (380).
  • the LTM application may send the vehicle data to the LTM backend service for analysis (385).
  • the data may be sent by a cellular connection.
  • the data may be sent by a WTRU, as set forth more fully below.
  • transmission of the vehicle data (e.g., monitoring of the target area) continues until the LTM application in the vehicle or the backend service stops the monitoring.
  • the LTM backend may then conduct analysis of data collected from all reporting vehicles (390), including the user's, as discussed above in relation to FIG. 2.
  • the LTM backend may utilize the vehicle to transmit warnings or other notifications, as discussed above in relation to FIG. 2.
  • the LTM application user interface (or human-machine interface, "UMI") for manually driven vehicles provides information about an available LTM parking place.
  • the UMI may further provide navigational routing to the LTM parking place, as illustrated in the exemplary embodiment of an UMI in FIG.
  • the UMI may provide a map of an area around the parking place, but not provide navigational routing.
  • the user may select to accept (e.g., confirm) the parking reservation or cancel it.
  • the HMI may present the LTM parking place to the user, without requiring user confirmation.
  • the HMI may provide information, such as about the parking place and reservation time (availability of the vehicle for LTM-service), and/or the like.
  • the availability time may be provided by the user, extracted from available user information (for example fetched from the user calendar), and/or the like.
  • the information about the LTM parking place presented by the HMI may include, but is not limited to, requirements of the parking place (e.g., minimum sensor categories, etc.), available amenities at the parking place (e.g., electric car charging, covered parking, free parking for certain sensor categories, the address of the parking place, distance from the user to the parking place, the direction for the user to approach the parking place for proper orientation of sensors, and/or the like.
  • requirements of the parking place e.g., minimum sensor categories, etc.
  • available amenities at the parking place e.g., electric car charging, covered parking, free parking for certain sensor categories, the address of the parking place, distance from the user to the parking place, the direction for the user to approach the parking place for proper orientation of sensors, and/or the like.
  • FIG. 5 An exemplary scenario utilizing an embodiment of the present disclosure is illustrated in FIG. 5.
  • the example describes an LTM service capable vehicle (Carl) parked in an LTM parking place near an intersection.
  • the main sensing direction is towards the intersection.
  • the environment sensor coverage of the vehicle is indicated with dotted lines 505, 510, 515, as such coverage may be for a particular vehicle or particular sensors of a particular vehicle.
  • this other LTM parking place may not be utilized by the LTM backend service, as the field-of-view (e.g., sensor coverage areas 505, 510, 515) of the vehicle's sensor systems cover the entire intersection.
  • the vehicle's sensors may not fully cover the intersection, and the other LTM parking place would be allocated by the LTM.
  • the LTM backend service may allocate multiple LTM parking places for a single location or intersection, despite complete coverage by a single vehicle. In some embodiments, the LTM backend service may allocate only a single LTM parking place, despite incomplete coverage by a single vehicle.
  • FIG. 6 Another exemplary scenario utilizing an embodiment of the present disclosure is illustrated in FIG. 6.
  • the example describes an LTM service capable vehicle (Car5) parked in an LTM service capable vehicle (Car5) parked in an LTM service capable vehicle (Car5) parked in an LTM service capable vehicle (Car5) parked in an LTM service capable vehicle (Car5) parked in an LTM service capable vehicle (Car5) parked in an LTM service capable vehicle (Car5) parked in an LTM service capable vehicle (Car5) parked in an LTM service capable vehicle (Car5) parked in an LTM service capable vehicle (Car5) parked in an LTM service capable vehicle (Car5) parked in an LTM service capable vehicle (Car5) parked in an LTM service capable vehicle (Car5) parked in an LTM service capable vehicle (Car5) parked in an LTM service capable vehicle (Car5) parked in an LTM service capable vehicle (Car5) parked in an LTM service capable vehicle (Car5) parked in an LTM service capable vehicle (Car5) parked in an LTM service capable vehicle (Car5) parked in
  • the school day is starting, soon there will be many children crossing here, and the location is known to be dangerous.
  • the environment sensor coverage (e.g., range and field-of-view) of the vehicle (Car5) is presented with dotted lines 605, as in one embodiment.
  • This vehicle has very limited sensor systems and the field of view and range of the system does not cover the monitoring area.
  • Another vehicle (Car6) has been allocated to take this LTM-parking place, and Car6 is driving there to complement the monitoring area coverage with its in-vehicle sensors.
  • the messages between actors in the disclosure can contain various information, depending on the context of the message.
  • An LTM parking query message may include, but is not limited to, the following information: Vehicle ID - vehicle identification; Vehicle location - value can be the vehicle coordinates (e.g., from GPS); Availability - how long the vehicle is available for the LTM-service
  • An LTM-parking place reservation message (e.g., reply from the LTM backend service) may include, but is not limited to, the following information: Location - the location (e.g., coordinates) of the reserved LTM parking place; Heading - the target heading of the vehicle after it is parked; and/or the like.
  • a vehicle sensor data request message may, in some embodiments, contain no information.
  • a Vehicle data reply message (or reply from Vehicle data access) may include, but is not limited to, the following information: vehicle sensor data, object detection, media containers, events, and/or the like.
  • Vehicle sensor data may comprise detailed vehicle sensor data values from all in-vehicle sensors including but not limited to: Time and date - e.g., time stamp; Position
  • Detection may comprise information about moving and static objects, including but not limited to: Object Position Offset; a moving 3D vector of the object; Object type, such as a classification
  • a Media Container (as described in, for example, the HERE Vehicle
  • Sensor Data Cloud Ingestion Interface specification may comprise data from vehicle sensors, such as a camera image or snapshot, a video feed, and/or the like, and further comprise information including but not limited to: Media type, format, content, ID, and/or the like; and Sensor offset, direction, media duration, sensor horizontal and/or vertical viewing angle, and/or the like.
  • Events may comprise Event detections (e.g., crash, emergency braking, obstacle on the road, possible or imminent collision, slippery road, etc.) that the vehicle can detect and classify, though the capabilities of the vehicle may vary depending on the particular embodiment.
  • TMC Event Codes can be used to report detected events.
  • a Send vehicle data message may include, but is not limited to, the following information: Vehicle ID - vehicle identification; Vehicle sensor data (see vehicle data reply message); Object detection (see vehicle data reply message); Media container (see vehicle data reply message); Events (see vehicle data reply message); and/or the like.
  • a Send warning message (from the LTM backend service) and the Distribute warning message may include, but is not limited to, information about the detected event or dangerous situation that should be distributed to the road users in the target area. These messages generally provide information about the event, event position, relevance area, etc.
  • the messages may be constructed by utilizing the available V2X communication standards from ETSI (e.g., DENM, from ETSI (2014) Intelligent Transport Systems (ITS); Vehicular Communications; Basic Set of Applications; Part 3 : Specifications of Decentralized Environmental Notification Basic Service. ETSI EN 302 637-3 Vl .2.2 (2014-11)) and SA, from SAE J2735 - Dedicated Short Range Communications (DSRC) Message Set Dictionary, December 2006 Version 1.0), and/or the like.
  • ETSI e.g., DENM, from ETSI (2014) Intelligent Transport Systems (ITS); Vehicular Communications; Basic Set of Applications; Part 3 : Specifications of Decentralized Environmental Notification Basic Service.
  • An LTM Ready to Activate message may inform the LTM backend service that the vehicle is ready to start the monitoring service when requested.
  • the message may include, but is not limited to, the following information: Vehicle ID - vehicle identification; vehicle state; and/or the like.
  • a Start monitoring message may include, but is not limited to, information regarding Sensor types, such as a list of sensor types and other data that the vehicle LTM application should start sending to the backend service (e.g., via a vehicle data reply message).
  • the LTM-service may, in some embodiments, operate without predefined and marked LTM parking places on the streets.
  • the LTM capable vehicles attempt to find the most suitable available parking place for monitoring and autonomous vehicles could try to find parking places when the traffic is low.
  • the LTM backend may maintain a hierarchy of preferred parking places at each location, such as ordered by monitoring capability from each parking place.
  • the vehicle database including the in-vehicle sensor specifications and vehicle LTM-service category may be implemented into the vehicle terminal.
  • one or more of the LTM parking places may be equipped with electric vehicle charging stations. Electric vehicles using the LTM service may be allocated preferably to these parking places and charging could be provided for free to the parked vehicles that are providing the monitoring data. V2I communication between the vehicle and the charging station may be utilized to identify the vehicle, start charging, etc. This may open new business opportunities for the service, such as providing incentives for users to allow use of their vehicles for the LTM service.
  • real-time and historical data gathered by the LTM service can be utilized, such as by autonomous vehicles (or vehicle platoons) planning a route through the area.
  • autonomous vehicles or vehicle platoons
  • autonomous vehicles could be routed through less demanding or risky intersections, or intersections where local traffic monitoring service are currently available.
  • the parking operator may also inform a police system API (or comparable system) about the allocation of an LTM parking place to a vehicle (with vehicle identification, e.g., vehicle register number, license plate, etc.) for the police (or city authority) parking control.
  • vehicle identification e.g., vehicle register number, license plate, etc.
  • unauthorized parking could be prevented.
  • unauthorized parking could be prevented by an electronically controlled vehicle barrier, which would open with V2I communication upon arrival of the vehicle to which the parking place is allocated.
  • the LTM backend service may instruct an LTM vehicle to tune its perception sensors according the current monitoring needs, e.g. to save vehicle energy by reducing the sensing frequency or the number (or types) of sensors.
  • the LTM backend service may instruct an LTM vehicle to increase the sensing frequency and/or the types of sensors being utilized.
  • parked vehicles providing LTM-service could also provide additional lights, in addition to existing street lights and/or the like, to the target area, for example by turning on headlights to further illuminate a crosswalk when there are pedestrians detected during dark hours.
  • Max works in a coffee shop and drives to work every day. He has had some trouble finding a parking place near his work on a side street in the city center. Now he has installed the LTM service in his electric vehicle and he is allowed to park his car in LTM parking places.
  • a later morning Max drives to work When he is near his working place, he activates the LTM application and it begins to search for a suitable LTM parking place. He has already set as a default value that the car is available for LTM-monitoring for 8 hours. The application shows that an LTM parking place is available at the next intersection for his car. He confirms the reservation of the parking place, and the application guides him there, using a GPS navigation module.
  • Max While Max parks the car he can see from the application HMI that his car is parked in the right direction and position, in order to have the best view towards the intersection with his in- vehicle sensors. When he stops the engine he observes that the LTM-application has started the monitoring service. At this point, Max can connect electric vehicle charging features available at this parking place, prior to leaving the area. In this scenario, the charging is provided for free in return for using the vehicle's sensors for the LTM system. Now he can go to work and his electric vehicle gets free charging and parking during the day while providing the monitoring data to the service.
  • Exemplary embodiments disclosed herein are implemented using one or more wired and/or wireless network nodes, such as a wireless transmit/receive unit (WTRU) or other network entity.
  • WTRU wireless transmit/receive unit
  • FIG. 7 is a system diagram of an exemplary WTRU 102, which may be employed as a communication module in embodiments described herein.
  • the WTRU 102 may include a processor 118, a communication interface 119 including 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 sensors 138.
  • GPS global positioning system
  • 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.
  • the transmit/receive element 122 may be configured to transmit signals to, or receive signals from, a base station over the air interface 116.
  • 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 MFMO 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 116.
  • 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.
  • a WTRU and/or another module may communicate via dedicated short range communications, IEEE 802. l ip, and/or the like. Such communications may, in some embodiments, enable V2V, V2I, or V2X communications.
  • the processor 118 of the WTRU 102 may be coupled to, and may receive user input data from, the speaker/microphone 124, the keypad 126, and/or the display/touchpad 128 (e.g., a liquid crystal display (LCD) display unit or organic light-emitting diode (OLED) display unit).
  • the processor 118 may also output user data to the speaker/microphone 124, the keypad 126, and/or the display/touchpad 128.
  • the processor 118 may access information from, and store data in, any type of suitable memory, such as the non-removable memory 130 and/or the removable memory 132.
  • the non-removable memory 130 may include random-access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device.
  • the removable memory 132 may include a subscriber identity module (SFM) card, a memory stick, a secure digital (SD) memory card, and the like.
  • 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). [0102]
  • 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.
  • dry cell batteries e.g., nickel-cadmium (NiCd), nickel- zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li -ion), and the like
  • solar cells e.g., 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 1 16 from a base station 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 sensors such as 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.
  • sensors such as 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
  • the WTRU, processor, modules, one or more vehicle sensors, and/or the like may be communicatively linked by a CAN bus and/or the like.
  • FIG. 8 depicts an exemplary network entity 190 that may be used in embodiments of the present disclosure, for example as a backend service. As depicted in FIG. 8, 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. As depicted in FIG. 8, data storage 196 contains program instructions 197 executable by processor 194 for carrying out various combinations of the various network-entity functions described herein.
  • a method comprising local traffic monitoring using a parked vehicle.
  • a system comprising a processor and a non-transitory computer-readable medium storing instructions that are operative, when executed on the processor, to perform functions including: local traffic monitoring using a parked vehicle.
  • a method comprising monitoring a selected street section with at least one parked connected vehicle.
  • the method further comprises allocating the connected vehicle to a first monitoring parking place at the selected street section according to predetermined monitoring needs in response to a parking query from the vehicle.
  • the step of allocating further comprises comparing sensor capabilities of the connected vehicle with predetermined monitoring needs of the selected street section.
  • the method further comprises receiving real-time sensor data from at least one sensor of the vehicle, wherein said real-time sensor data is sent while the vehicle is stationary.
  • method further comprises collecting sensor data from a plurality of connected vehicles allocated to a plurality of selected street sections.
  • the connected vehicle comprises an autonomous vehicle, and further comprising sending a replacement parking allocation to the vehicle.
  • the replacement parking allocation comprises a second monitoring parking place at a second selected street section.
  • a method comprising: establishing a database of street sections for monitoring, wherein said database comprises at least one LTM parking place for each monitored street section; receiving a parking request from a vehicle; and allocating at least one LTM parking place to said vehicle.
  • a system comprising a processor and a non-transitory computer-readable medium storing instructions that are operative, when executed on the processor, to perform functions including: establishing a database of street sections for monitoring, wherein said database comprises at least one LTM parking place for each monitored street section; receiving a parking request from a vehicle; and allocating at least one LTM parking place to said vehicle.
  • a method comprising: sending a parking query from a first vehicle to an LTM backend server; receiving a parking place reservation from the LTM backend server, wherein said reservation includes data indicating a location of the parking place; navigating the first vehicle to the location of the parking place; parking in alignment with a heading received from the LTM backend server; collecting data from at least a first vehicle sensor; and transmitting real-time vehicle sensor data from the vehicle to the LTM backend server.
  • the method further comprises, in response to a warning received from the LTM backend server, distributing said warning to at least one other road user.
  • said warning is distributed by a V2X communication.
  • the vehicle comprises an autonomous vehicle.
  • the step of parking further comprises communicating with an electronically controlled vehicle barrier to access the reserved parking place. In one embodiment, communicating with the barrier further comprises communicating by a V2I communication. In one embodiment, the step of parking further comprises verifying that the line of sight to a target area is free. In one embodiment, if the line of sight is not free, further comprising requesting another parking place from the LTM backend server. In one embodiment, if the line of sight is not free, further comprising reporting a detected obstruction to the LTM backend server.
  • a system comprising a processor and a non-transitory computer-readable medium storing instructions that are operative, when executed on the processor, to perform functions including: sending a parking query from a first vehicle to an LTM backend server; receiving a parking place reservation from the LTM backend server, wherein said reservation includes data indicating a location of the parking place; navigating the first vehicle to the location of the parking place; parking in alignment with a heading received from the LTM backend server; collecting data from at least a first vehicle sensor; and transmitting real-time vehicle sensor data from the vehicle to the LTM backend server.
  • there is a method comprising: receiving a parking query from a first vehicle at an LTM backend server; sending a parking place reservation from the LTM backend server to the first vehicle, wherein said reservation includes data indicating a location of the parking place; sending an alignment heading for vehicle positioning from the LTM backend server to the first vehicle; and receiving real-time vehicle sensor data from the vehicle at the LTM backend server.
  • the method further comprises receiving sensor data from a plurality of vehicles allocated to parking places in a target area.
  • a system comprising a processor and a non-transitory computer-readable medium storing instructions that are operative, when executed on the processor, to perform functions including: receiving a parking query from a first vehicle at an LTM backend server; sending a parking place reservation from the LTM backend server to the first vehicle, wherein said reservation includes data indicating a location of the parking place; sending an alignment heading for vehicle positioning from the LTM backend server to the first vehicle; and receiving real-time vehicle sensor data from the vehicle at the LTM backend server.
  • a method comprising: sending a parking query from a first autonomous vehicle to an LTM backend server; receiving a monitoring location from the LTM backend server, wherein said monitoring location includes data indicating optimal sensor coverage of the location; navigating the first vehicle to the monitoring location; determining a parking place near the monitoring location, wherein determining further comprises comparing a real-time sensor coverage of the location by the first vehicle to the optimal sensor coverage; parking in the determined parking place; collecting data from at least a first vehicle sensor; and transmitting realtime vehicle sensor data from the vehicle to the LTM backend server.
  • a system comprising a processor and a non-transitory computer-readable medium storing instructions that are operative, when executed on the processor, to perform functions including: sending a parking query from a first autonomous vehicle to an LTM backend server; receiving a monitoring location from the LTM backend server, wherein said monitoring location includes data indicating optimal sensor coverage of the location; navigating the first vehicle to the monitoring location; determining a parking place near the monitoring location, wherein determining further comprises comparing a real-time sensor coverage of the location by the first vehicle to the optimal sensor coverage; parking in the determined parking place; collecting data from at least a first vehicle sensor; and transmitting realtime vehicle sensor data from the vehicle to the LTM backend server.
  • a method comprising: sending a parking query from a first vehicle to an LTM backend server; receiving a parking place reservation from the LTM backend server, wherein said reservation includes data indicating a location of a reserved parking place; while the vehicle is parked in the reserved parking place: collecting data from at least a first vehicle sensor; and transmitting real-time vehicle sensor data from the vehicle to the LTM backend server.
  • the method further comprises displaying the location of the reserved parking place on a user interface to a driver of the first vehicle.
  • 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.

Landscapes

  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Business, Economics & Management (AREA)
  • Atmospheric Sciences (AREA)
  • Life Sciences & Earth Sciences (AREA)
  • Engineering & Computer Science (AREA)
  • Chemical & Material Sciences (AREA)
  • Analytical Chemistry (AREA)
  • Tourism & Hospitality (AREA)
  • Economics (AREA)
  • Strategic Management (AREA)
  • Theoretical Computer Science (AREA)
  • Human Resources & Organizations (AREA)
  • Marketing (AREA)
  • General Business, Economics & Management (AREA)
  • Quality & Reliability (AREA)
  • Development Economics (AREA)
  • Operations Research (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Primary Health Care (AREA)
  • Traffic Control Systems (AREA)

Abstract

L'invention concerne des systèmes et des procédés pour surveiller des intersections à l'aide d'un serveur principal de service de surveillance de trafic local pour se coordonner et communiquer avec des véhicules connectés. Un procédé peut consister en l'enregistrement d'un véhicule connecté auprès d'un serveur, indiquant au moins un capteur embarqué. Le serveur peut recevoir du véhicule connecté une demande de stationnement dans une certaine plage autour d'un premier emplacement. Le serveur peut déterminer un emplacement de surveillance dans la plage autour du premier emplacement, la surveillance requise utilisant ledit capteur embarqué du premier véhicule connecté. Le serveur peut sélectionner au moins une place de stationnement disponible associée à l'emplacement de surveillance déterminé. Le serveur peut envoyer au premier véhicule connecté des informations concernant une première place de stationnement parmi la ou les places de stationnement disponibles déterminées. Le serveur peut ultérieurement demander des données en temps réel audit capteur embarqué du premier véhicule connecté.
PCT/US2017/021417 2016-03-14 2017-03-08 Procédés et systèmes pour surveiller des intersections avec des véhicules connectés à l'arrêt WO2017160562A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201662308067P 2016-03-14 2016-03-14
US62/308,067 2016-03-14

Publications (1)

Publication Number Publication Date
WO2017160562A1 true WO2017160562A1 (fr) 2017-09-21

Family

ID=58387932

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2017/021417 WO2017160562A1 (fr) 2016-03-14 2017-03-08 Procédés et systèmes pour surveiller des intersections avec des véhicules connectés à l'arrêt

Country Status (1)

Country Link
WO (1) WO2017160562A1 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10882521B2 (en) 2018-02-21 2021-01-05 Blackberry Limited Method and system for use of sensors in parked vehicles for traffic safety
CN114726897A (zh) * 2022-04-11 2022-07-08 厦门科拓软件研发中心有限公司 一种车场远程坐席通道服务系统

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102014009627A1 (de) * 2014-06-27 2014-11-27 Daimler Ag Verfahren zur Meldung einer freien Parklücke für ein Fahrzeug
US20150066545A1 (en) * 2013-09-03 2015-03-05 Verizon Patent And Licensing Inc Mobile parking systems and methods for providing real-time parking guidance
US20150070196A1 (en) * 2013-09-11 2015-03-12 Here Global B.V. Method and apparatus for determining an adjustment in parking position based on proximate parked vehicle information
US20160068187A1 (en) * 2013-04-26 2016-03-10 Toyota Jidosha Kabushiki Kaisha Parking assist device

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20160068187A1 (en) * 2013-04-26 2016-03-10 Toyota Jidosha Kabushiki Kaisha Parking assist device
US20150066545A1 (en) * 2013-09-03 2015-03-05 Verizon Patent And Licensing Inc Mobile parking systems and methods for providing real-time parking guidance
US20150070196A1 (en) * 2013-09-11 2015-03-12 Here Global B.V. Method and apparatus for determining an adjustment in parking position based on proximate parked vehicle information
DE102014009627A1 (de) * 2014-06-27 2014-11-27 Daimler Ag Verfahren zur Meldung einer freien Parklücke für ein Fahrzeug

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
ETSI EN 302 637-3 V1.2.2, November 2014 (2014-11-01)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10882521B2 (en) 2018-02-21 2021-01-05 Blackberry Limited Method and system for use of sensors in parked vehicles for traffic safety
CN114726897A (zh) * 2022-04-11 2022-07-08 厦门科拓软件研发中心有限公司 一种车场远程坐席通道服务系统
CN114726897B (zh) * 2022-04-11 2023-12-08 厦门科拓软件研发中心有限公司 一种车场远程坐席通道服务系统

Similar Documents

Publication Publication Date Title
US20240038063A1 (en) Traffic monitoring and management systems and methods
CN108417087B (zh) 一种车辆安全通行系统及方法
US11630998B2 (en) Systems and methods for automatically training neural networks
US11935402B2 (en) Autonomous vehicle and center control system
US10730512B2 (en) Method and system for collaborative sensing for updating dynamic map layers
US9911334B2 (en) Connected vehicle traffic safety system and a method of warning drivers of a wrong-way travel
CN106448254B (zh) V2x车联网系统、车载终端、服务端以及车位检测方法
US9373255B2 (en) Method and system for producing an up-to-date situation depiction
WO2018128946A1 (fr) Procédé d'émission d'avertissements aux usagers vulnérables de la route dans un angle mort d'un véhicule stationné
US20120136559A1 (en) Device and system for identifying emergency vehicles and broadcasting the information
CN113874803A (zh) 用于基于远程干预更新车辆操作的系统和方法
Scholliers et al. Integration of vulnerable road users in cooperative ITS systems
CN111354214B (zh) 一种辅助停车方法和系统
US20150317901A1 (en) Method and system for learning traffic events, and use of the system
CN113409607A (zh) 路况信息推送系统、方法、装置、设备及存储介质
CN111724616A (zh) 基于人工智能的数据获取及共享的方法与装置
CN112396856A (zh) 一种路况信息获取方法、交通标识牌及智能网联交通系统
CN113167592A (zh) 信息处理设备、信息处理方法和信息处理程序
CN114041176A (zh) 安全性能评价装置、安全性能评价方法、信息处理装置和信息处理方法
WO2021261228A1 (fr) Dispositif de gestion d'informations d'obstacle, procédé de gestion d'informations d'obstacle et dispositif pour véhicule
CN113748448A (zh) 基于车辆的虚拟停止线和让行线检测
WO2017160562A1 (fr) Procédés et systèmes pour surveiller des intersections avec des véhicules connectés à l'arrêt
Park et al. Glossary of connected and automated vehicle terms
JP2023171455A (ja) 経路予測装置、それを備えた車載装置、経路予測システム、経路予測方法、及びコンピュータプログラム
Annur et al. Information and communication technology (ICT) for intelligent transportation systems (ITS)

Legal Events

Date Code Title Description
DPE1 Request for preliminary examination filed after expiration of 19th month from priority date (pct application filed from 20040101)
NENP Non-entry into the national phase

Ref country code: DE

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

Ref document number: 17712627

Country of ref document: EP

Kind code of ref document: A1

122 Ep: pct application non-entry in european phase

Ref document number: 17712627

Country of ref document: EP

Kind code of ref document: A1