STATIONARY CONNECTED VEHICLES

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] The present application is a non-provisional filing of, and claims benefit under 35 U.S.C §119(c) from, U.S. Provisional Patent Application Serial No. 62/308,067, filed March 14, 2016, entitled "METHODS AND SYSTEMS FOR MONITORING INTERSECTIONS WITH STATIONARY CONNECTED VEHICLES", which is incorporated herein by reference in its entirety.

TECHNICAL FIELD

[0002] This disclosure relates to systems and methods for sensor and communication systems of connected vehicles.

BACKGROUND

[0003] 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.

[0004] New Advanced Driver Assistance Systems (ADAS) and the development of automated driving has increased the use of environment perception systems and propelled advances in the computing power in modern vehicles. These perception systems are able detect and classify various objects, such as vehicles and other road users, including Vulnerable Road Users (VRU) which include pedestrians, cyclists, motorcyclists, and other road users without the protection of the body of a vehicle. However, these perception systems still have limitations in detecting and classifying VRUs and their behaviors, especially in urban environment. These limitations include: a line of sight between in-vehicle sensors and the target is needed by most of the sensors; object classification errors, e.g., how to differentiate between an empty plastic bag and a running child; in-vehicle computing power is still limited, and therefore the time required by object detection may not be sufficient, especially at higher vehicle speeds (> 80 km/h); multiple objects in the same area (e.g., crowded intersections) may block the visual on-sight view of one or more objects; and others.

[0005] Connected vehicles and V2X (vehicle-to-everything) communication have been suggested to mitigate some of these problems. For example, 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. There is also known an inter-vehicle or collaborative perception method where vehicles share their sensory data or detected objects via V2V communication. Furthermore, V2X communication has been planned to be extended also to VRUs, in order to provide warnings or dangerous situations for both vehicles and VRUs.

SUMMARY

[0006] Described herein are systems and methods related to monitoring intersections with stationary connected vehicles.

[0007] 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. In some embodiments, 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.

[0008] 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. Especially the automated vehicles and their advanced sensor systems should be utilized as much as possible for the benefit of other road users. 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.

[0009] The present disclosure is advantageous for a variety of reasons. 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.

[0010] Further, 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.

[0011] 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.

[0012] 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.

[0013] For the above and other reasons, 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.

BRIEF DESCRIPTION OF THE DRAWINGS

[0014] A more detailed understanding may be had from the following description, presented by way of example in conjunction with the accompanying drawings, wherein:

[0015] FIG. 1 illustrates an exemplary embodiment of a general architecture for an LTM service and devices.

[0016] FIG. 2 illustrates an exemplary embodiment of a process for using an LTM service with an autonomous vehicle.

[0017] FIG. 3 illustrates an exemplary embodiment of a process for using an LTM service with a manually driven vehicle.

[0018] 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.

[0019] 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. [0020] 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.

[0021] FIG. 7 illustrates an exemplary wireless transmit/receive unit (WTRU) that may be employed as a communication module in some embodiments.

[0022] FIG. 8 illustrates an exemplary network entity that may be employed in some embodiments.

DETAILED DESCRIPTION

[0023] A detailed description of illustrative embodiments will now be provided with reference to the various Figures. Although this description provides detailed examples of possible implementations, it should be noted that the provided details are intended to be by way of example and in no way limit the scope of the application.

[0024] Note that various hardware elements of one or more of the described embodiments are referred to as "modules" that carry out (e.g., perform, execute, and the like) various functions that are described herein in connection with the respective modules. As used herein, a module includes hardware (e.g., one or more processors, one or more microprocessors, one or more microcontrollers, one or more microchips, one or more application-specific integrated circuits (ASICs), one or more field programmable gate arrays (FPGAs), one or more memory devices) deemed suitable by those of skill in the relevant art for a given implementation. Each described module may also include instructions executable for carrying out the one or more functions described as being carried out by the respective module, and 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.

[0025] Implementation of new intelligent roadside equipment comes at substantial cost to road operators and cities which deploy them on their road network. These costs may include software and hardware of the roadside equipment, cabling, installation, training, maintenance and upgrading, and still others as well. Infrastructure investments and support are still needed while connected and more intelligent vehicles are coming to the market. Moreover, the infrastructure is mostly implemented and maintained by public authorities which are not always fast enough to follow the latest technology development trends.

[0026] Existing solutions and new systems such as collaborative perception and local (short- range) 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. Currently, it is also unclear if cities are ready to equip intersections (especially minor crossings, or suburban areas) with intelligent sensor systems and local V2I communication technology.

[0027] There are a number of potential road/street locations which would benefit from intelligent roadside infrastructure if costs of these systems could be reduced. Such locations may include intersections or crossings without traffic signals; pedestrian crossings or crosswalks near schools, nurseries, bars or night clubs, or elder living facilities; railway grade crossings; and/or the like. The reality is that public funding is always limited, and without collaboration between the private and public sector the infrastructure will not develop quickly enough to optimally serve future autonomous driving needs. Moreover, the sensor technology of roadside infrastructure is not developing as fast as the technology in the vehicle industry, and it would be highly beneficial to utilize the modern in-vehicle technology for infrastructure monitoring as well. However, the problem remains how to deploy traffic monitoring technologies to the roadside with limited resources of the road operators and cities.

[0028] In-vehicle sensing technologies, computing power (including advanced algorithms), and communication capabilities (especially cellular connectivity) of vehicles are developing quickly. Autonomous and semi-automated vehicles are coming to the market with state-of-the art environment perception, computing, and communication systems. Especially automated vehicles and their advanced sensor systems should ideally be utilized as much as possible to contribute to other road users' benefit. These vehicles are also in many cases electric or hybrid (or other non- gasoline based, such as hydrogen) vehicles where in-vehicle electric energy storage is very large. This fact enables in-vehicle sensing, computing, and communication system usage while they are parked and not in use. Computing power requirements for stationary or parked vehicle environment sensing are not as high as for vehicles moving at higher speeds, further reducing the limits on use of parked vehicles to contribute to a local traffic monitoring infrastructure.

[0029] 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.

[0030] Vehicle. The first vehicle can be an autonomous or manually driven vehicle. Generally, the vehicle comprises: an in-vehicle terminal, and at least one vehicle sensor. [0031] In some embodiments, 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. In some embodiments, 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. In some embodiments, one or more of the communication systems may comprise a WTRU, as more fully disclosed below.

[0032] In some embodiments, 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). In some embodiments, such as for manually driven vehicles, 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. In some embodiments, a digital map database and locations of LTM parking places may be part of a remote cloud server, accessible to the in-vehicle terminal.

[0033] In some embodiments, the in-vehicle terminal may comprise a wireless transmit/receive unit, as further discussed below.

[0034] 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.

[0035] Backend for Local Traffic Monitoring service. In some embodiments, 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.

[0036] In one embodiment, 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. In some embodiments, 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. [0037] A parking place allocation module of the backend may function to efficiently manage distributing LTM parking places to available vehicles. In some embodiments, 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. In some embodiments, 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.).

[0038] 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. 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. In various embodiments, 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. In some embodiments, 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.

[0039] 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

(e.g., weather reports, traffic data, known road constructions, etc.), and/or the like. 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.

[0040] In some embodiments, the backend may comprise a wireless transmit/receive unit, as further discussed below.

[0041] Other vehicles and road users. Other nearby vehicles and/or 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.

[0042] An exemplary process for an autonomous vehicle using the LTM service is illustrated in FIG. 2.

[0043] In the exemplary embodiment, it is assumed that 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. In some situations, LTM parking places can be the first on-street parking places towards the target area, or the like. In some embodiments, 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. Further, 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. Additionally, connected vehicles, which are capable of providing LTM services, are registered into the LTM service backend. Accordingly, the vehicle sensor specifications (including sensor types; sensor ranges; fields-of-view; communication capabilities; object detection, classification, and tracking capabilities; etc.) of registered vehicles is stored to the vehicle database module of the service. Generally, in-vehicle sensor specifications will be used to classify vehicles to LTM service categories.

[0044] At some time, there is an LTM application activation (205). In some embodiments, 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. [0045] After activation, 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.

[0046] After the request, 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.

[0047] In some embodiments, 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. Exemplary incentives may include, for example, a parking credit or discount or other form of compensation.

[0048] In some embodiments, 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.

[0049] Generally, the autonomous vehicle then drives to the location of the allocated parking place and initiates parking, such as between steps 230 and 235.

[0050] As the vehicle arrives at the allocated parking place and begins parking, 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. In some embodiments, prior to, during, or after automated parking maneuvers, 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. In some embodiments, if the place is not clear, 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).

[0051] After the vehicle is parked, the monitoring of the target area may begin. 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. In some embodiments, the response information may depend on the available vehicle sensors.

[0052] Once received, the LTM application may send the vehicle data to the LTM backend service for analysis (255). In some embodiments, the data may be sent by a cellular connection. In other embodiments, the data may be sent by a WTRU, as set forth more fully below. Generally, 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.

[0053] 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.

[0054] In some embodiments, 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.

[0055] In some embodiments, 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. In an exemplary embodiment, upon receiving such a message 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. In some other embodiments, 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. In another embodiment, 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. [0056] An exemplary process for a manually driven vehicle using the LTM service is illustrated in FIG. 3. In some embodiments involving manually-driven vehicles, 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.

[0057] In the manual driven car embodiment of FIG. 3, at some point 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. In another embodiment, 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. In a further embodiment, the user may input a distance around the destination location within which the LTM parking place must be found. In another embodiment, 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).

[0058] After activation, the LTM application may request available LTM parking locations from the LTM backend service (310). 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, 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.

[0059] After the request, 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.

[0060] In some embodiments, 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.

[0061] In some embodiments, once received, 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). One embodiment of such an HMI is illustrated in FIG. 4. In some embodiments, the user may be prompted to confirm the allocated parking place. Upon confirmation (340), a reservation confirmation message (e.g., a Reservation OK message) may be sent to the backend service (345). In some embodiments, 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).

[0062] 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).

[0063] In some embodiments, while the user is parking the vehicle, 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). In some embodiments, 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. In such an embodiment, 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).

[0064] In some embodiments, 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. In such embodiments, 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).

[0065] In some embodiments, prior to, during, or after parking maneuvers, the LTM application, vehicle, and/or the user (such as through the HMI) may verify to the LTM service that the parking place is available and that the line of sight to the target area is free. In some embodiments, if the place is not clear, 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).

[0066] Once the user has finished parking (e.g., with the vehicle engine stopped, vehicle in park, user has left the vehicle) (352), the LTM may be ready to activate. In some embodiments, when the LTM is 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). In some embodiments, 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. In such an embodiment, 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.

[0067] At some later time, 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.

[0068] Once monitoring is initiated, the local LTM application may request real-time data from the in-vehicle sensors (370). In response, the vehicle may get sensor data (375), and there may be a vehicle data reply with the requested real-time vehicle sensor data (380). Once received, the LTM application may send the vehicle data to the LTM backend service for analysis (385). In some embodiments, the data may be sent by a cellular connection. In other embodiments, the data may be sent by a WTRU, as set forth more fully below. Generally, 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.

[0069] 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. In some embodiments, the LTM backend may utilize the vehicle to transmit warnings or other notifications, as discussed above in relation to FIG. 2.

[0070] User interface (or Human-Machine Interface). The LTM application user interface (or human-machine interface, "UMI") for manually driven vehicles provides information about an available LTM parking place. In some embodiments, the UMI may further provide navigational routing to the LTM parking place, as illustrated in the exemplary embodiment of an UMI in FIG.

4. Such routing could be provided by a satellite navigation module in the vehicle, the LTM application, operating on the LTM backend, and/or the like. In some embodiments, the UMI may provide a map of an area around the parking place, but not provide navigational routing. In some embodiments, the user may select to accept (e.g., confirm) the parking reservation or cancel it. In some embodiments, the HMI may present the LTM parking place to the user, without requiring user confirmation. In further embodiments, 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. In some embodiments, 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. In some embodiments, 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.

[0071] 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. In the scenario, there is also another LTM parking place facing towards the intersection, but on the other side of the intersection in the opposite direction of travel. In one embodiment, given the sensor coverage of the 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. In other embodiments, the vehicle's sensors may not fully cover the intersection, and the other LTM parking place would be allocated by the LTM.

[0072] In some embodiments, 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.

[0073] 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 parking place and oriented towards a crosswalk in front of a school. 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. There is also another LTM parking place on the other side of the street near the crosswalk, in the other direction of travel. 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.

[0074] Message protocol. In various embodiments, the messages between actors in the disclosure can contain various information, depending on the context of the message.

[0075] 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

(e.g., in hours); and/or the like.

[0076] 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.

[0077] A vehicle sensor data request message may, in some embodiments, contain no information.

[0078] 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

Estimate (using, for example, the HERE Vehicle Sensor Data Cloud Ingestion Interface

Specification, as found in HERE (2015) Vehicle Sensor Data Cloud Ingestion Interface

Specification (v2.0.2)); Accurate vehicle position (coordinates) and position accuracy; Vehicle heading and heading accuracy; Vehicle orientation (e.g., yaw/roll/pitch-rotation value);

Environment status (using, for example, the HERE Vehicle Sensor Data Cloud Ingestion Interface specification), the combination of information covering the outside environment, such as detected light conditions, weather data (e.g., temperature, precipitation, visible distance, etc.). Object

Detection (using, for example, the HERE Vehicle Sensor Data Cloud Ingestion Interface specification) 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

(e.g., moving/static vehicle, truck, bike, person or a pedestrian, etc.); Object size; Reference to media ID; and/or the like. 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. In some embodiments, TMC Event Codes can be used to report detected events.

[0079] 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.

[0080] 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.

[0081] 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.

[0082] 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).

[0083] The LTM-service may, in some embodiments, operate without predefined and marked LTM parking places on the streets. In such embodiments, 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. In some embodiments, the LTM backend may maintain a hierarchy of preferred parking places at each location, such as ordered by monitoring capability from each parking place.

[0084] In some embodiments, the vehicle database including the in-vehicle sensor specifications and vehicle LTM-service category may be implemented into the vehicle terminal. [0085] In some embodiments, 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.

[0086] In some embodiments, 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. For example, autonomous vehicles could be routed through less demanding or risky intersections, or intersections where local traffic monitoring service are currently available.

[0087] In some embodiments, 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.

[0088] In some embodiments, wherein the LTM parking places are predetermined and marked, unauthorized parking could be prevented. In one embodiment, 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.

[0089] In some embodiments, 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. In other embodiments, in response to increasing monitoring needs, the LTM backend service may instruct an LTM vehicle to increase the sensing frequency and/or the types of sensors being utilized.

[0090] In some embodiments, 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.

[0091] An exemplary use case scenario is set forth below. 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.

[0092] 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.

[0093] 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.

[0094] 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.

[0095] FIG. 7 is a system diagram of an exemplary WTRU 102, which may be employed as a communication module in embodiments described herein. As shown in FIG. 7, 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. It will be appreciated that the WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with an embodiment.

[0096] 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. 7 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. [0097] The transmit/receive element 122 may be configured to transmit signals to, or receive signals from, a base station over the air interface 116. For example, in one embodiment, the transmit/receive element 122 may be an antenna configured to transmit and/or receive RF signals. In another embodiment, the transmit/receive element 122 may be an emitter/detector configured to transmit and/or receive IR, UV, or visible light signals, as examples. In yet another embodiment, the transmit/receive element 122 may be configured to transmit and receive both RF and light signals. It will be appreciated that the transmit/receive element 122 may be configured to transmit and/or receive any combination of wireless signals.

[0098] In addition, although the transmit/receive element 122 is depicted in FIG. 7 as a single element, 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.

[0099] The transceiver 120 may be configured to modulate the signals that are to be transmitted by the transmit/receive element 122 and to demodulate the signals that are received by the transmit/receive element 122. As noted above, the WTRU 102 may have multi-mode capabilities. Thus, the transceiver 120 may include multiple transceivers for enabling the WTRU 102 to communicate via multiple RATs, such as UTRA and IEEE 802.11, as examples.

[0100] In some embodiments, 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.

[0101] The processor 118 of the WTRU 102 may be coupled to, and may receive user input data from, the speaker/microphone 124, the keypad 126, and/or the display/touchpad 128 (e.g., a liquid crystal display (LCD) display unit or organic light-emitting diode (OLED) display unit). The processor 118 may also output user data to the speaker/microphone 124, the keypad 126, and/or the display/touchpad 128. In addition, the processor 118 may access information from, and store data in, any type of suitable memory, such as the non-removable memory 130 and/or the removable memory 132. The non-removable memory 130 may include random-access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 may include a subscriber identity module (SFM) card, a memory stick, a secure digital (SD) memory card, and the like. In other embodiments, the processor 118 may access information from, and store data in, memory that is not physically located on the WTRU 102, such as on a server or a home computer (not shown). [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. As examples, the power source 134 may include one or more dry cell batteries (e.g., nickel-cadmium (NiCd), nickel- zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li -ion), and the like), solar cells, fuel cells, and the like.

[0103] The processor 118 may also be coupled to the GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to, or in lieu of, the information from the GPS chipset 136, the WTRU 102 may receive location information over the air interface 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.

[0104] The processor 118 may further be coupled to other peripherals 138, which may include one or more software and/or hardware modules that provide additional features, functionality and/or wired or wireless connectivity. For example, the peripherals 138 may include 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.

[0105] In some embodiments, 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.

[0106] 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.

[0107] 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.

[0108] 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.

[0109] 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.

[0110] Additional Embodiments. In an embodiment, there is a method comprising local traffic monitoring using a parked vehicle. In an embodiment, there is 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.

[0111] In an embodiment, there is a method comprising monitoring a selected street section with at least one parked connected vehicle. In one embodiment, 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. In one embodiment, the step of allocating further comprises comparing sensor capabilities of the connected vehicle with predetermined monitoring needs of the selected street section. In one embodiment, 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. In one embodiment, then method further comprises collecting sensor data from a plurality of connected vehicles allocated to a plurality of selected street sections. In one embodiment, the connected vehicle comprises an autonomous vehicle, and further comprising sending a replacement parking allocation to the vehicle. In one embodiment, the replacement parking allocation comprises a second monitoring parking place at a second selected street section. [0112] In an embodiment, there is 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: monitoring a selected street section with at least one parked connected vehicle.

[0113] In an embodiment, there is 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.

[0114] In an embodiment, there is 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.

[0115] In an embodiment, there is 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. In one embodiment, 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. In one embodiment, said warning is distributed by a V2X communication. In one embodiment, the vehicle comprises an autonomous vehicle. In one embodiment, 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.

[0116] In an embodiment, there is 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.

[0117] In an embodiment, 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. In one embodiment, the method further comprises receiving sensor data from a plurality of vehicles allocated to parking places in a target area.

[0118] In an embodiment, there is 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.

[0119] In an embodiment, there is 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.

[0120] In an embodiment, there is 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.

[0121] In an embodiment, there is 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. In one embodiment, the method further comprises displaying the location of the reserved parking place on a user interface to a driver of the first vehicle.

[0122] Although features and elements are described above in particular combinations, one of ordinary skill in the art will appreciate that each feature or element can be used alone or in any combination with the other features and elements. In addition, the methods described herein may be implemented in a computer program, software, or firmware incorporated in a computer- readable medium for execution by a computer or processor. Examples of computer-readable storage media include, but are not limited to, a read only memory (ROM), a random access memory (RAM), a register, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD- ROM disks, and digital versatile disks (DVDs). A processor in association with software may be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.