WO2017136283A1 - System and method for adaptively informing road users about a temporary traffic disturbance - Google Patents

Abstract

Methods and systems are described for routing and/or rerouting vehicles based on predicted route blockages, such as pre-scheduled stops by delivery vehicles or other wide vehicles. In an exemplary embodiment, a system such as a navigation server obtains information including a scheduled stop location of a first vehicle, such as a delivery truck, and a predicted time during which the first vehicle is predicted to be at the stop location. The system further obtains information regarding an initial route of a second vehicle. The system determines whether the first vehicle would block the route of the second vehicle and, if so, the system computes an alternate route for the second vehicle.

Description

SYSTEM AND METHOD FOR ADAPTIVELY INFORMING ROAD

USERS ABOUT A TEMPORARY TRAFFIC DISTURBANCE

CROSS-REFERENCE TO RELATED APPLICATION

[0001] The present application is a non-provisional filing of, and claims benefit under 35 U.S.C §119(e) from, U.S. Provisional Patent Application Serial No. 62/292,025, entitled "System and Method for Adaptively Informing Road Users About a Temporary Traffic Disturbance," filed February 5, 2016, the entirety of which is incorporated herein by reference.

Background

[0002] Traffic, especially in cities, easily gets congested. In many cities around the world the volume of the traffic, especially during rush hour, is so high that even a minor disturbance in traffic causes congestions and delays for travelers. Minor temporal traffic disturbances may potentially result in disturbances for all road/street users such as Heavy Goods Vehicles, delivery/garbage trucks and vans, ordinary cars, autonomous cars, 2-3-wheelers: bicycles, motorcycles, scooters, wheelchairs, etc. and pedestrians, including those with sliding/rolling accessories such as roller blades and skateboards.

[0003] Several fixed and vehicle mounted systems have been developed to detect traffic disturbances and congestions such as traffic flow measurement systems, probe data from vehicles or mobile phones (e.g. Here, Google), and users can share traffic information via community-based traffic and navigation applications such as Waze. Traffic information may be collected by various authorities, private companies and organizations and may be provided to drivers via multiple channels, applications and devices. Congestion information is predicted from the collected history data and real-time data from various sources. Waze is a mobile application that enables users to report, share, and use traffic disturbance information for currently present traffic disturbances in real-time.

[0004] In high-traffic urban areas, ad hoc traffic congestion occurrences, e.g., due to service delivery/moving vehicles, etc. cannot be reliably foreseen. When such congestion occurs, the congestion grows and affects the accuracy (e.g., duration/location) of traffic management and navigation systems during peak hours. Such congestion may be ad-hoc congestions caused by delivery vehicles. Such congestions may be difficult to handle by traffic management/navigation systems as the location of the root cause of the event and duration are unknown. By the time traffic congestion occurrences are detected or reported (via Waze etc.), quite a few vehicles are already affected by the situation. Summary

[0005] Methods and systems are described for routing and/or rerouting vehicles based on predicted route blockages, such as pre-scheduled stops by delivery vehicles or other wide vehicles. In an exemplary embodiment, a system such as a navigation server obtains information including a scheduled stop location of a first vehicle, a predicted time during which the first vehicle is predicted to be at the stop location, a width of the first vehicle, and a road dimension at the stop location. The system further obtains information regarding an initial route of a second vehicle and a width of the second vehicle. In a case where the initial route passes the stop location during the predicted time, the system determines, based on the road dimension and the width of the first and second vehicles, whether the first vehicle would block passage of the second vehicle. In response to a determination that the first vehicle would block passage of the second vehicle, the system computes an alternate route for the second vehicle.

[0006] Further, methods and systems are described herein for adaptively informing and warning local drivers about a temporary ad-hoc local traffic disturbance. Such disturbances may occur on roads, city streets/lanes and/or sidewalks. In some embodiments, the warning is generated by a vehicle (e.g. delivery vehicles, cars, motor-/bicycles) or other road user. The warning and/or traffic information can be provided to any road user device via short-range (e.g. Vehicle-to-X (V2X)) or wide area communication. In some embodiments, the warning is generated in advance of a traffic obstruction if the time and location of the disturbance is known beforehand (e.g. the next stop of the delivery vehicle) and updated when the disturbance can be more accurately described. In some embodiments, the warning is generated when a disturbance begins (e.g. a vehicle parking in front of a coffee shop, or a group of pedestrians crossing a street). In some embodiments, the user/vehicle initiating a traffic disturbance may use the vehicle's sensors to generate detailed data on how much it blocks the street/lane/sidewalk. The system processes this data to determine how much of the road is free and delivers this information to other road users via metric values, percentages, or any other visual and/or graphical formats. Other road users /vehicles receive the warning, processes the data, and determine whether or not they are able to pass. In some embodiments, the Human-Machine Interface (HMI) displays icons/symbols representing which type of vehicle or other road users are able to pass, and may provide re-routing for vehicles unable to pass if needed.

[0007] Further, methods and systems are disclosed for local traffic disturbance street/road/lane blockage notifications before a future occurrence based on accurately known/estimated information regarding the future occurrence. In some embodiments, real-time notifications may be provided to a Traffic Management Center (TMC) via V2X communication from the vehicle that will be creating the disturbance.

[0008] In some embodiments, a system informs/warns other vehicles or road/street users (including early warning in advance) about a temporary short-term traffic disturbance by utilizing local V2V/V2I/V2X and wide area communication systems. In some embodiments, the warnings include time, location, duration and disturbance properties and street/road blocking measurements.

[0009] In some embodiments, the V2X communications utilize various messaging protocols between vehicles, other road users and backend systems.

[0010] In some embodiments, the warnings include dynamic indicators for vehicle/ mobile device HMIs and "Able to pass traffic disturbance" indicators.

[0011] In some embodiments, a blocking vehicle measures and calculates properties of the caused traffic disturbance such as which part of the street (vehicle lane, bike lane, sidewalk) the traffic disturbance will be created, and to which road users (trucks, vans, cars, motorcycles, cyclists, pedestrians) the disturbance will be relevant.

[0012] In some embodiments, the system includes real-time selective indicator delivery, receiving and expression for relevant vehicles or street/road users

[0013] Services are being developed for ad-hoc package delivery to parked cars. Such services will increase instances of partial blocking of lanes/streets so that only certain types of vehicles are able to pass. In order to ensure fluent traffic flow, these events may be detected, interpreted and information or warnings may be shared adaptively to affected vehicles/street users in embodiments described herein.

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 depicts an example client device, in accordance with some embodiments.

[0016] FIG. 2 is a high-level block diagram of a system architecture in accordance with some embodiments.

[0017] FIG. 3 is a sequence diagram for disturbance estimation and a pre-warning process, in accordance with some embodiments.

[0018] FIG. 4 depicts an example scenario, in accordance with some embodiments.

[0019] FIG. 5 is a sequence diagram for blocking rate calculation, warning update, and a clearance process, in accordance with some embodiments. [0020] FIG. 6 depicts an example scenario, in accordance with some embodiments.

[0021] FIG. 7 depicts examples of symbols for different road users including a van, family car, sport car, bike, and pedestrian, in accordance with some embodiments.

[0022] FIGs. 8A-8D depict example UMI views of a blocking vehicle/user, in accordance with some embodiments.

[0023] FIGs. 9A-9C depict example UMI views of a local vehicle/user, in accordance with some embodiments.

[0024] FIG. 10 is a sequence diagram for obtaining information, determining if a disturbance will occur, and calculating an alternative route in accordance with some embodiments.

DETAILED DESCRIPTION

[0025] 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. The systems and methods relating to ad-hoc communication may be used with the wired and wireless communication systems described with respect to FIG. 1 , which is described at the end of the detailed description.

[0026] Existing solutions mentioned above cannot predict randomly occurring disturbances. Real-time data from the disturbances can be generated only after congestion or a traffic jam has already begun and is detected. For certain disturbances (e.g. a pre-planned road construction) the TMC may have the information in advance and broadcast or deliver the information via various channels to local drivers. However, in many cases the TMC or any other private traffic information collectors do not have prior information of smaller disturbances.

[0027] When the volume of the traffic is high, even a minor disturbance can cause local traffic jams. Drivers that are caught in the traffic jam can generate information about the situation after detecting the disturbance. In many cases the driver's journey may be significantly delayed, or in the most severe case the driver is unable to continue his/her journey until the disturbance clears.

[0028] An example of a temporary short-term traffic disturbance in a city is caused by vehicles that stop or park on the street, at least partially blocking a street, a bike lane or a sidewalk. Larger vehicles that require a lot of space and time to park create longer and more severe local disturbances to the traffic flow. Such vehicles include delivery cars, trucks/vans, waste collecting vehicles, etc. In many situations these vehicles violate traffic or parking rules while carrying out their tasks and at the same time generate local traffic disturbances, affecting the surrounding traffic, especially when the traffic volumes are high. Currently such disturbances are detected and reported to the traffic information systems only after the traffic jam has occurred. Furthermore, an accurate location of the cause of traffic disturbance and duration are not usually known. In most existing solutions, a user may see a large section of a road having traffic congestion without knowing where the actual disturbance (e.g., an accident, broken down car, etc.) has occurred within that large section of road. Delays in information delivery to the road users may occur when the temporary disturbance is cleared (e.g. the accident cleared or delivery done). For instance, the update of the current situation may be reported to the traffic information system prior to the road users receiving the update.

[0029] The increase of on-line shopping, home-delivery and various peer-to-peer delivery services is expected to make this problem even worse in the near future. Therefore, such traffic disturbances will grow as a variety of professional and non-professional drivers alike will be delivering goods and services as well as other similar activities that cause traffic disturbances. In many cases the location, time and potential traffic disturbance are known beforehand by the vehicle drivers. In such cases, the driver may be on a specific delivery schedule. A warning based on this schedule information could be provided to other road users and traffic management systems prior to the driver making his/her delivery to alleviate the impact of their operations.

[0030] Current systems or applications do not generally provide information or warnings in advance. Furthermore, existing solutions are unable to interpret or measure which type of vehicle, bike rider, and/or pedestrian can pass around the stopped vehicle causing the traffic disturbance.

[0031] FIG. 2 is a high-level block diagram of a system architecture in accordance with some embodiments. As shown, FIG. 2 illustrates a street-blocking road user 205, a local traffic disturbance service 207, and other road users 209. As shown, the street-blocking road user includes a primary terminal, which may be running a Local Traffic Disturbance (LTD) mobile application. In some embodiments, the LTD application is configured to estimate possible traffic disturbances 204 that a driver/user is about to cause in advance (e.g. for a next scheduled stop).

In some embodiments, the traffic disturbance estimate is based on the user's vehicle dimensions

212/220, a description of another traffic-blocking obstacle, information regarding current traffic conditions on the destination street, etc. In some embodiments, the LTD application is configured to calculate or estimate how much the user's vehicle blocks the street/lane/sidewalk

202 based on vehicle dimensions 212 and vehicle sensor data 214 obtained via sensors disposed on the user's vehicle, as well as any other sensor disposed within the environment (e.g., pressure sensors underneath the pavement). In some embodiments, if the vehicle sensor data is not available, an estimation of lane blockage can be fixed or provided by the user, especially if history information regarding similar deliveries has been retained. In some embodiments, vehicle sensor data is irrelevant, such as in the case where the user is a pedestrian. In some embodiments, vehicle sensor information is processed to provide an estimate as to which vehicle types can freely pass the traffic obstruction. In some embodiments, subsequent to processing the vehicle sensor information, the LTD application is further configured to generate pre-warnings 206 to send using a communication device 208 in advance of the traffic disturbance and updated warning messages to send for the duration of the traffic disturbance to other road users and backend systems. In some embodiments, the LTD application generates messages to city parking operators and receives data from the city parking operators via communication networks 225. In some embodiments, the warning and/or messages may be transmitted using short-range (e.g. V2X or DSRC) and/or wide area wireless communication (e.g. cellular) systems via local communication networks 227.

[0032] In some embodiments, the street-blocking road user 205 includes a vehicle connected to the primary terminal (e.g. in-vehicle terminal), the vehicle including a digital map database 210. In some embodiments, the vehicle includes a database of the vehicle dimensions 212. In some embodiments, the vehicle captures real-time vehicle sensor data, e.g. positioning obtained via GPS or similar positioning systems and stores the sensor data 214. In some embodiments, the real-time vehicle sensor data includes environment information obtained via perception sensors, e.g. lidar, camera, ultrasonic sensors, etc. In some embodiments, the vehicle includes a user interface (UI) 216 for presenting road blocking information to the user. In some embodiments, the user may interact with the UI 216 to control, edit, enable manipulation of the information and share the information manually.

[0033] In some embodiments, the street-blocking road user has a mobile terminal or device.

Such embodiments may be beneficial in situations where the user is a pedestrian, a bike rider, or any other type of road user that is not associated with a vehicle having its own terminal. In some embodiments, the mobile terminal may take the form of a cellular device, a mobile phone, a tablet, a computer, or any other mobile device. In some embodiments, the mobile terminal may include or have access to a digital map database 218, which may include information similar to the information in a digital map database 210 of a vehicle. In some embodiments, the mobile terminal may store dimensions of the user of the mobile terminal 220. In some embodiments, the dimensions are preset, either temporarily or permanently. In such embodiments, the user may edit the dimensions based on a number of companions. For example, the mobile terminal may store dimension information for a bicycle. In some embodiments, the mobile terminal may include a positioning module 222, such as GPS or any other known positioning system. In some embodiments, the mobile terminal includes a UI 224 (which may be similar to UI 216) for presenting road-blocking information on the vehicle/road user device UI.

[0034] FIG. 2 depicts an example of an LTD service 207 between various users. As shown, the LTD service 207 provides message delivery 228 between the street-blocking road user's

LTD application and other information sources via communication networks 225. In some embodiments, the LTD service 207 provides messages via fleet management Application

Program Interfaces (APIs), providing information regarding the next stopping location of the vehicle (e.g. the delivery schedule and addresses). In some embodiments, the LTD service 207 provides messages via a parking operator API, including parking fee information for short-term local traffic disturbance-causing users. In some embodiments, the LTD service 207 provides messages via Traffic Management Centre (TMC) APIs. In some embodiments, the TMC APIs provide real-time traffic information about a requested street for the obstructing user's LTD application. In some embodiments, the TMC APIs handle and distribute pre-warning and updated warning messages about short-term temporary traffic disturbances to other local users in the area. In some embodiments, the LTD service 207 provides messages via police system APIs.

In such embodiments, police officers may receive information about authorized short-term street blockages. In some embodiments, the LTD service 207 may include a server that performs at least some of the functions performed by the delivery and/or local road users' terminals. In some embodiments, the server obtains information including a scheduled stop location of a first vehicle, a predicted time during which the first vehicle is predicted to be at the stop location, a width of the first vehicle, and a road dimension at the stop location and obtains information including an initial route of a second vehicle and a width of the second vehicle, wherein the initial route passes the stop location during the predicted time. The server then determines whether the first vehicle would block passage of the second vehicle based on the road dimension and the width of the first and second vehicles. In response to a determination that the first vehicle would block passage of the second vehicle, the LTD server computes an alternate route for the second vehicle, and may provide the computed alternate route to the second vehicle. In some embodiments, the LTD server may also provide the warning using a warning notifier.

[0035] FIG. 2 also illustrates local road users 209, which receive the LTD messages from the obstructing user or TMC API via the LTD service 207. In some embodiments, each of the local road users 209 may be provided with any subset of the following components. In some embodiments, the road users are provided with respective primary terminals. In some embodiments, the primary terminal may be similar to the primary terminal of the obstructing road user. In some embodiments, the primary terminal includes an LTD application that may perform blocking calculations 230, monitors possible local traffic disturbances 232 on the user's route and/or near the user's current location by receiving via a communication module 234 traffic disturbance warning messages via the local or wide area communication networks 225/227. In some embodiments, the LTD application determines if a received warning affects the local user or her/his vehicle she/he is currently driving using blocking effect calculator 230. In some embodiments, the LTD application may show the warning to the local user only if needed (e.g., if the obstruction takes place on the local user's current navigation route) via UIs in the vehicle (UI 240) and/or a mobile device (UI 248). In some embodiments, the local users receive messages via short-range (e.g. V2X or DSRC) communications systems 225 and/or wide area wireless communication (e.g. cellular) systems 227.

[0036] The local road users may also be provided with a vehicle similar to the vehicle described above for the obstructing user including a digital map 236, vehicle dimension information 238, and a UI 240. Further, the local road users may be provided with a mobile terminal similar to the mobile terminal described above. In some embodiments, one of the UIs 240/248 may be triggered to display blocking information/alert icons based on (i) choosing the turning lane towards a blocked street, and/or (ii) on activating turning-signal. In some embodiments, the vehicle may use information in the current navigation route to display the blocking information, and accordingly reroute.

[0037] As described above, while FIG. 2 illustrates blocking rate calculation, disturbance estimators, and warning notification units in the road users' terminals, it should be noted in some embodiments the LTD service may also include such functionalities. In some embodiments, such an LTD service (e.g., a server) may obtain information from the street blocking user and other road users, calculate traffic disturbances, and based on the disturbance, calculate alternative routes for the other road users, and provide the alternative routes to the other road users. In some embodiments, the LTD server may also issue a warning the road users that are receiving the computed alternative routes. Such embodiments are described in further detail below, with regards to FIG. 10.

[0038] FIG. 3 illustrates a sequence diagram for disturbance estimation and a pre-warning process. In some embodiments, the in-vehicle system or backend system has information about the potential disturbance location (e.g. next address or delivery stop), time and estimated duration of the potential traffic disturbance which the road user is going to cause. In some embodiments, the vehicle detects its location on the street area, using lidar sensors for example.

In some embodiments, the location may be determined by GPS or other positioning systems, sensors disposed on the vehicle, or any combination thereof. In some embodiments, a user may estimate the vehicle's dimensions. Alternatively, the vehicle dimensions may be predefined/predetermined or otherwise known by the vehicle and/or the LTD server (e.g., a vehicle database). In some embodiments, the vehicle may use sensors to provide estimates as to how much of the traffic lane, bike-lane, sidewalk (or other types of lane) are blocked when the vehicle is parked based on the known location on the street and the dimensions of the vehicle.

[0039] In some embodiments, the LTD application automatically starts 302 based on the delivery schedule and current position of the vehicle (e.g. if the vehicle is within some predetermined distance from the next destination). In some embodiments, the application may be manually started by the user. In some embodiments, the LTD application requests 304 the address of the next stop from an LTD server which directs the query 306 to a Fleet Management API. The next destination address (as well as the duration of a previous similar delivery at this address, if available) is provided 308 in the response from the LTD server back to the obstructing vehicle/user using the LTD application. In some embodiments, the LTD application requests 310 the current traffic situation for the next stop (next delivery address) from the LTD server, which may redirect the query 312 to the TMC API, which replies with a traffic report 314. In some embodiments, the LTD server requests destination and delivery information from a Fleet Management server, and obtains information from the delivery vehicle and one or more other vehicles to perform disturbance estimation and route recalculating internally.

[0040] In some embodiments, the LTD application calculates a disturbance estimation 316. If a disturbance is likely to occur, the LTD application generates a Local Traffic Disturbance event and issues a pre-warning to the LTD application in a second vehicle (Car 2) 320 as well as the LTD server 328, and the in-vehicle Human-Machine Interface (HMI) of Car 1 (the lane- blocking vehicle) is updated 318 with the issued pre-warning. The LTD application checks route relation 322 with respect to the pre-warning, checks vehicle relation 324, and updates an HMI of Car 2 326. In some embodiments, the LTD server distributes 330 the pre-warning to the TMC, police, etc. In some embodiments, the disturbance estimation is calculated by the LTD server, and a warning is issued to local road users via the server (not shown). In addition, the LTD server may obtain scheduled routes from the local road users and provide alternative routes to the local road users based on the disturbance estimation.

[0041] FIG. 4 illustrates an example scenario, in accordance with some embodiments. As shown, the scenario includes a delivery truck (Car 1) driving towards the next delivery stop

(shown as an 'X') which is on the right-hand-side after the next street crossing. The system in

Car 1 starts the LTD application, calculates a disturbance estimation, and starts sending the pre- warning message to other road users (e.g. to Car 2 following the truck and Car 3 waiting at a traffic light at the intersection). In some embodiments, Car 1 sends a pre-warning local message to the local road users and/or roadside units using a warning notification unit. In some embodiments, the warning includes various pieces of information such as time of disturbance, location of disturbance, and affected driving direction, a disturbance duration estimate, as well as any disturbance properties such as an identification (ID) number of Car 1, the type of vehicle, and traffic lane/bike-lane/sidewalk blocking estimation (e.g. percentage).

[0042] In some embodiments, the pre-warning messages are sent via V2X communication links 425 and 430. Subsequent to Cars 2 and 3 receiving the pre-warning messages, each car can perform a rerouting operation to avoid the soon-to-be traffic jam. In some embodiments, Car 1, 2, and/or 3 may relay the pre-warning to the roadside unit (RSU) 420 linked to the traffic lights. Further, RSU 420 can distribute the warning to other road users approaching the intersection for the duration of the traffic obstacle e.g., by including the warning in the traffic light V2I messaging.

[0043] In some embodiments, the LTD application in the receiving terminal of another road user (Car 2) checks if the received warning is valid for Car 2. In some embodiments, the LTD application in the receiving terminal checks route relation, and compares the location of Car 1 to the route of Car 2. In some embodiments, the LTD application of Car 2 checks vehicle relation by comparing the street blocking data received from Car 1 against the dimensions of Car 2. In some embodiments, if the received warning affects Car 2 in any way (e.g., on Car 2's route), the warning is displayed via the HMI in Car 2. In some embodiments, the warning may be presented via a navigation application. In some embodiments, the LTD application of Car 2 provides an alternative route if Car 2 is unable to pass an obstruction caused by Car 1. In some embodiments, Car 1 and/or Car 2 may provide a pre-warning message to the TMC (API) via the warning notification unit, which may then distribute the information to other road users in a wider range.

[0044] In some embodiments, rather than Car 1 providing warnings directly to Cars 2 and 3, Car 1 may alternatively provide information to a LTD server, which may then calculate and distribute pre-warning messages for Cars 2 and 3, and provide Cars 2 and 3 with calculated alternative routes to avoid a disturbance at the destination location.

[0045] FIG. 5 is a sequence diagram for blocking rate calculation, warning update, and a clearance process. Subsequent to the vehicle stopping/parking at the destination, a vehicle sensor request is sent 502 by the LTD application for the vehicle to gather sensor data 504. The vehicle provides sensor data 506 gathered by sensors disposed on the vehicle. In some embodiments, the sensor data includes positioning data, detailed dimension data of the street/lanes/sidewalks, and detailed dimension data of the vehicle. In some embodiments, the sensors may include lidar sensors, ultrasonic sensors, optical sensors, infrared sensors, cameras, or any other sensors known to those of skill in the art. Further any combination of such sensors may be used. In some embodiments, the blocking rate is calculated 508 in LTD application for each section and lane of the street, and provides that information in the warning update. In some embodiments, the HMI of the blocking car is updated 510 to display the level or amount of lane blockage. At 512 and 520, the warning updates are sent to an LTD application of Car 2 and the LTD server, respectively.

[0046] In alternative embodiments, vehicle dimension information may be contained in the LTD server, and Cars 1 and 2 may provide the LTD server with a car make and model, and the LTD server may obtain the vehicle dimensions via an internal vehicle database. Further, the LTD server may also include or have access to a map database that includes road width information.

[0047] In some embodiments, the LTD application in the blocking vehicle may send 520 disturbance data to the city parking operator API and/or the Police API via the LTD server 522, depending on use case. The LTD application may periodically send updated warning messages to local road users and roadside units 512 via the warning notification unit. In some embodiments, the messages include similar parameters as the pre-warning message along with detailed street and lane blocking information.

[0048] The LTD application of Car 2 periodically checks if the received warning update message is valid for Car 2. This check may be similar for the pre-warning check described above. In some embodiments, periodically checking the received warning update message includes checking route relation 514 by comparing location of the warning to the route of Car 2. In some embodiments, periodically checking the warning update message includes checking vehicle relation 516 by comparing street blockage data in the warning to known vehicle dimensions of Car 2. In some embodiments, if the warning is valid for Car 2, HMI in Car 2 is updated 518, and the terminal of Car 2 may provide rerouting if needed.

[0049] In alternative embodiments, warnings are received directly from the LTD server based on a calculated disturbance estimation. In such embodiments, Car 2 may also receive an alternative route directly from the LTD server, alleviating the LTD application running on Car 2 from having to check route relations.

[0050] In some embodiments, the HMI of Car 1 may be updated 510, confirming that the updated warning has been issued and sent to other road users. In some embodiments, the updated warning messages are sent (periodically or continuously) to the TMC, which may relay the updated warning messages to other users in a wider range. In some embodiments, the HMI of Car 1 may be updated in response to receiving a confirmation message from the LTD server that warnings have been distributed to other road users.

[0051] Once the delivery vehicle is started 524, the HMI may be update 526, and cancel warning may be sent 528 and 532 to Car 2 and the LTD server, respectively. In response, Car 2 may update the HMI to clear the warning 530. Further, the LTD server may distribute the cancellation warning 534 to TMC, police, etc.

[0052] FIG. 6 depicts an example scenario. The scenario includes a delivery truck 605 parked on the bike-lane while making a delivery. The LTD estimates a blocking rate calculation and estimates the magnitude of the possible traffic disturbance caused by the delivery event by measuring the relative positions of the vehicle with respect to map data regarding traffic lanes/bike lanes/sidewalks and other vehicle sensor data. As shown in FIG. 6, the truck does not block the sidewalk (0%), fully blocks the bike-lane (100%) and partially blocks the traffic lane (60%)). The traffic on the street is high and there are many cars driving in the opposite direction. Therefore, passing the truck may be difficult for cars or other large vehicles, as well as unsafe for bicyclists. An updated warning message is sent to local road users 610/615/620/625 e.g., via V2X communications systems, or distributed using an LTD server.

[0053] In some embodiments, the delivery event start is detected by the LTD application. The HMI of the delivery truck is updated and a warning is generated. In some embodiments, the warning is sent locally to other road users. For the local users, the warning is checked, and the local users' vehicles may update their respective HMIs to display the warning to the user in the vehicle. In some embodiments, the warning is also sent to the TMC (as well as parking operators and/or police systems in some embodiments), which may distribute the warning messages to users over a larger range.

[0054] In some embodiments, user interfaces for the vehicle/road user blocking the street, as well as for other local road users are utilized for receiving and displaying information/warnings.

In some embodiments, special traffic disturbance parking permits may be organised by using this system and UI by broadcasting the warning to the parking operators' API.

[0055] In some embodiments, the local road users receive the data shared by the blocking vehicle, e.g. actual details of the blocking event, blocked and free street data. Each local user processes the received data according to their own details (such as properties and dimensions of the user's vehicle/bike/pedestrian) into an interpretation expressing whether or not the user will be able pass the blocking event. In some embodiments, the interpretation is shown using symbols and/or new updated route option on the map. Examples of the symbols for different road users: van, family car, sport car, bike, and pedestrian are presented in FIG. 7. For bicyclists or pedestrians, the symbol can be shown on a personal device, e.g., on a smart phone. Symbols in the top row, which may be displayed with a green triangular border (represented as a solid border in FIG. 7), can be used to illustrate that there is a road block and the particular vehicle or user is able to pass. Symbols in the middle row, which may be displayed with an orange or yellow triangular border (represented as a large hashed border in FIG. 7), can be used to illustrate that a road block is present, and that passing requires careful attention. Symbols in the bottom row, which may be displayed with a red border (represented as a small hashed border in FIG. 7), may represent a case in which a road user is not able to pass the blocking event. In some embodiments, colours or patterns of the symbols may provide passing recommendations. Further, icons or text labels may be used to characterize the symbols.

[0056] The objective of the user interface for the vehicle/road user which is causing the partial road disturbance is to confirm to the blocker that (s)he understands the traffic disturbance action (s)he is causing, as well as the data of the blocking event. In some embodiments, the data of the blocking event includes vehicle details. In some embodiments, the data includes schedule information. In some embodiments, the data includes the type of event. The data is then shared to corresponding local entities, such as traffic systems, other local vehicles, and possibly other third party systems such as parking systems. In some embodiments, the blocking user can manually edit the data.

[0057] FIGs. 8A-8D depicts various exemplary views of a UI or UMI, in accordance with some embodiments. FIGs. 8A-8D are exemplary views of a UI for the blocking user. The UI of FIG. 8A displays basic information for the blocking event such as, time data, address, coordinates (centre of the vehicle), event type, and vehicle/road user measurements, etc. In some embodiments, the vehicle/road user measurements are joint e.g., if the user is outside the vehicle. In some embodiments, the measurements include other objects that the user provides, such as parking cones, etc.

[0058] FIG. 8B depicts an exemplary UMI view of event details for a traffic disturbance, in accordance with some embodiments. As shown, the event details include how much of the road/lanes are blocked or free. In some embodiments, the lane blockage is represented as a percentage. In some embodiments, the lane blockage is represented as a unit of measurement e.g., feet, meters, yards, etc. In some embodiments, the event details include which side of the street the blocking vehicle occupies.

[0059] FIG. 8C depicts an exemplary UMI view of which users will be able to pass, presented as symbols (similar to the symbols shown in FIG. 7). Further, the UMI of FIG. 8C includes road sides represented via passable directions North and South. [0060] FIG. 8D depicts an exemplary UI view for confirming the data is correct, and subsequently sending the data. In some embodiments, the HMI includes an input to edit the data. FIG. 8D also includes optional traffic services such as parking permit acceptance and payments, in accordance with some embodiments. FIG. 8D also includes an option to send the data to a TMC for longer range broadcasting.

[0061] FIGs. 9A, 9B and 9C depict exemplary embodiments of an HMI for a user receiving the warning from a blocking user. As shown in FIG. 9A, the user interface for other road users who may potentially be affected by a traffic disturbance may include easy-to-understand representations, such as colour, patterned symbols, and/or labels/images providing explanation of which type of vehicles/road users are able to pass the blocking event. In some embodiments, the HMI may offer an alternative route to destination if blocking event occurs on the planned route, as shown in FIG. 9B.

[0062] FIG. 9C depicts an exemplary embodiment of an HMI as shown on a mobile phone, in accordance with some embodiments, such as in pedestrian use cases.

[0063] The following are various examples of message protocol, in accordance with some embodiments.

Next Delivery Address

[0064] In some embodiments, the Next delivery address query message may include the following information:

Vehicle ID - vehicle identification.

Vehicle location - value can be the vehicle coordinates (e.g. from GPS).

Time and date - current time and date.

- Previous delivery ID - value can be e.g. identification of previous delivery on the

delivery schedule or list depending on the system used.

[0065] In some embodiments, the next address message (reply from a Fleet management system) includes the following information:

- Next destination address - the address or location (e.g., coordinates) of the next delivery stop.

Time of the delivery - estimated time of the next delivery.

- Estimated duration - estimated duration of the next stop (time needed for

unloading/loading and the delivery). In some embodiments, this duration may be estimated based on durations of previous similar deliveries to the address. - Previous traffic disturbance - estimation of the traffic disturbance calculated from data of previous visits.

Traffic disturbance properties

[0066] In some embodiments, the LTD server may request the Next Delivery Address for use in performing the disturbance estimation calculation, and may calculate and provide alternative routes to any affected road users. In alternative embodiments, the delivery vehicle may request the Next Delivery Address, and provide the destination, time of delivery, and estimated duration information directly to other road users in the area.

Traffic Information Request

[0067] In some embodiments, the Traffic information query message includes the following information:

- Street address - address of the next delivery. More generally, a scheduled stop location for a vehicle.

Time and date - estimated time of the delivery. This may include a predicted time during which the vehicle will be at the scheduled location.

[0068] In some embodiments, the Traffic information message (reply from TMC or similar) includes the following information:

Traffic report - estimated volume of the traffic in the street at specified time.

Local Traffic Disturbance Event (Pre-Warning)

In some embodiments, the pre-warning local message (V2X) includes any combination of the following information

Warning ID - Identification of the pre-warning.

Time and date - predicted time and date of the traffic disturbance start.

- Location - coordinates of the traffic disturbance.

- Affected driving direction - Direction(s) of the traffic which is affected by the

disturbance.

- Duration estimation - estimation of the duration of the traffic disturbance.

Traffic disturbance properties such as:

o Vehicle ID and type - Blocking vehicle identification and type (e.g. delivery

truck, van, car, ...). In the case of a mobile user (e.g. a pedestrian), this can include the identification of the mobile application and type of a road user (pedestrian). In some embodiments, the vehicle identification includes parameters such as make, model, and year of a particular vehicle,

o Lane blocking estimation:

^■ Traffic Lane

• Lane 1 - blocking estimation percentage/di stance unit

• Lane ...

• Lane n - blocking estimation percentage/di stance unit

^■ Bike-lane - blocking estimation percentage/di stance unit

^■ Sidewalk - blocking estimation percentage/di stance unit

^■ Other lanes - blocking estimation percentages/di stance unit

[0069] In some embodiments, the pre-warning message to be sent to backend systems (e.g. the TMC) includes information similar to that of the pre-warning local message described above for V2X communication.

[0070] In some embodiments, the pre-warnings are provided from the LTD server based on a disturbance estimation calculated from obtained information including:

a scheduled stop location of a first vehicle

a predicted time during which the first vehicle is predicted to be at the stop location a width of the first vehicle

a road dimension at the stop location

a width of the second vehicle

an initial route of a second vehicle, the initial route passing the stop location during the predicted time

Traffic Information (obtained from TMC in some embodiments) at the stop location. Blocking Rate Calculation

[0071] In some embodiments, the vehicle sensor request message requests sensor data from the vehicle. In response, the vehicle data message provides available sensor, map and vehicle data. In some embodiments, the vehicle data message includes any combination of the following information:

Vehicle location - accurate positioning data based on data obtained e.g. from GPS, inertial measurement unit and other vehicle sensors, and map matching

- Map data - detailed map data of the street and lanes including their dimensions (e.g. width of the traffic lane (or lanes), bike-lane and sidewalk)

Vehicle dimension - dimensions of the vehicle [0072] The Vehicle sensor request message requests sensor data from the vehicle. The Vehicle data message provides available sensor, map and vehicle data. It includes the following information:

Vehicle location - accurate positioning data based on data obtained e.g. from GPS, inertial measurement unit and other vehicle sensors, and map matching

- Map data - detailed map data of the street and lanes including their dimensions (e.g. width of the traffic lane (or lanes), bike-lane and sidewalk)

Vehicle dimension - dimensions of the vehicle

Local Traffic Disturbance Event

[0073] Subsequent to the traffic disturbance starting, the LTD server (or blocking vehicle) may issue a warning local message that may include the following information:

Warning ID - Identification of the warning (linked to the pre-warning)

Time and date - Time and date of the traffic disturbance start

- Location - Coordinates of the traffic disturbance

- Affected driving direction - Direction(s) of the traffic which is affected by the

disturbance

- Duration estimation - Estimation of the duration of the traffic disturbance

Traffic disturbance properties such as

o Vehicle ID and type - Blocking vehicle identification and type (e.g. delivery

truck, van, car, ...). In case of a mobile user (e.g. a pedestrian), this can be also the identification of the mobile application and type of a road user (pedestrian). o Lane blocking measurements:

^■ Traffic lane

• Lane 1 - blocking percentage/di stance unit

• Lane ...

• Lane n - blocking percentage/di stance unit

^■ Bike-lane - blocking percentage/di stance unit

^■ Sidewalk - blocking percentage/di stance unit

^■ Other lanes- blocking percentages/distance unit

- Alternative Route - for road users that will be affected by the disturbance, alternative routes may be computed by the LTD server and distributed to the affected users.

[0074] In some embodiments, the warning message sent to the backend system (e.g. TMC) includes information similar to that of the warning local message described above. Vehicle Start Event

[0075] In some embodiments, when the blocking vehicle is started and ready to depart, the vehicle sends a cancel warning local message (V2X) to surrounding vehicles/users. In some embodiments, the vehicle sends a cancel warning to the LTD server, which then distributes the cancel warning to other road users affected by the disturbance event. In some embodiments, the LTD servers recalculates alternative routes in response to receiving a cancel warning message. In some embodiments, cancel warnings are not needed due to any originally affected vehicles bypassing the disturbance location. In some embodiments, the cancel warning local message includes the following information:

Warning ID - Identification of the cancellation of the warning (linked to the pre-warning and warning messages)

[0076] In some embodiments, the cancel warning message sent to backend systems (e.g. TMC) includes the same information as the cancel warning local message described above.

[0077] Embodiments described above provide advanced information and warnings regarding short-term local traffic disturbances for other drivers and road users in vicinity of the short-term local traffic disturbance. Vehicles that need to stop/park for a short time and disturb the traffic can utilize this system for sending warnings. For vehicles in which the next stop/destination is known in advance, the vehicles can generate pre-warnings such as:

i. Post/packet/parcel delivery (and pickup)

ii. Garbage-removal

iii. Food/groceries delivery service

iv. Emergency vehicles (police, ambulance, ...)

v. Tow trucks

vi. Moving / removal vans/trucks

vii. Elderly / special groups transport

viii. Shared ride vehicle or van

[0078] In some embodiments, other road users such as pedestrians and bikers may cause a traffic disturbance, and may generate warning messages with a mobile device (e.g. a smart phone). Some example scenarios include:

i. A group of young children (e.g. a nursery group) walking on the sidewalk (e.g.

coming from a building and going to a parked bus).

ii. A large group of pedestrians coming from a building e.g. after an event has ended. iii. Persons loading a truck/van. Even if the parked vehicle does not cause the traffic disturbance, the loading may block/disturb pedestrians walking on the sidewalk, for example.

[0079] Local road users in the vicinity of the blocking vehicle/user may obtain information about blocked streets based on dimensions of the blocking vehicle and lanes/sidewalks the blocking vehicle is currently or will be occupying. In some embodiments, a car driver might see via the system HMI that a street blocked, but motorcyclists, cyclists and pedestrians might see it as open.

[0080] In some embodiments, traffic information systems, providers and navigators as well as city authorities may receive accurate data regarding local traffic disturbances. In some embodiments, that data includes when a traffic disturbance occurs, where the traffic disturbance occurs, the duration of the traffic disturbance, how much street/lane/sidewalk are blocked due to the disturbance, as well as notifications for when the disturbance clears.

[0081] In embodiments described herein, drivers or other road users who need to stop the vehicle (e.g. for delivery) on the street/lane/sidewalk and block or otherwise disturb the traffic may minimize the consequences. Consequently, a delivery company's reputation may be enhanced by utilizing such a system if the severity of traffic disturbances is reduced.

[0082] In some cases, cities may charge and put in place higher parking fees for vehicles which disturb the traffic, providing an incentive to use above-described embodiments. In other cases, police may determine that a vehicle causing a traffic disturbance has a temporary permit by receiving warnings from the vehicle. Other advantages include less congestion and pollution in the cities, less time wasted in traffic, and greater traffic safety.

[0083] In some embodiments, a user may make a parking payment according to a caused traffic disturbance. When the vehicle is stopped, information about the measured street/lane blockage is sent to the city parking operator API. In some embodiments, the parking operator system calculates a parking payment based on current parking fees in the area/street and how much vehicle is blocking the other traffic. The city parking operator system may reply to the vehicle that short-term stopping/parking is allowed with an associated parking fee. In some embodiments, the fee associated with a disturbance may be higher than the normal fee. In some embodiments, the vehicle driver sees via the HMI, the parking fee for the estimated stopping duration and accepts an online payment for the parking fee. Subsequently, the parking operator may inform the police (API) that the temporary traffic disturbance causing short-term parking is authorized. When the delivery is done and vehicle is started, a parking payment ending message is sent to the parking operator. [0084] In some embodiments, city authorities (e.g. parking operator or police) can provide permits to an obstructing vehicle (or driver/user) to use the LTD application and cause local traffic disturbances and send warnings to other road users. The LTD application registers to the city authorities (API) and obtains a permit. In some embodiments, the permit may be checked or validated by a parking control or a local police car (e.g. driving by the stopped vehicle) by receiving the local warning message and comparing the vehicle ID to a list of authorized or permitted vehicles.

[0085] In some embodiments, if a large vehicle activates automatic or starts manual parking on a narrow street (which takes time and blocks other traffic for some time), a similar traffic disturbance local warning message may be sent to other road users (vehicles, cyclists, pedestrians) nearby e.g. via V2X communication, or distributed via an LTD server. Based on the dimensions of the vehicle and the street/lanes and volume of the traffic, the message may include an estimation of how long (e.g. 2 minutes) the traffic will be disturbed and which lanes and road users are affected.

[0086] In some embodiments, the backend system of the delivery truck/van/car (or any other similar vehicle) learns from each delivery stop where the vehicle has been parked and if the parking has caused a traffic disturbance due to stopping on the street or sidewalk. In some embodiments, such learning of the local traffic jam may be based on data from V2X communication between the vehicle and other local road users, and traffic data, e.g. from the TMC. The size or number of packages being delivered and the stopping time is also recorded in order to make better estimates of the traffic disturbance for a subsequent similar delivery.

[0087] In some embodiments, the application in the vehicle that expects to create a local traffic disturbance (e.g., Two Guys and a Truck, UPS Delivery, Amazon delivery) queries the next destination address from its fleet management database, the server provides the address and estimated duration to reach that location, the LTD application in the vehicle queries the current traffic situation at the destination from the server, the server delivers the estimated traffic volume, the LTD application displays to the user the information at hand and calculates the disturbance impact by data from vehicle sensors and destination characteristics and sends a pre- warning to the server including (i) the estimated time it will be at the destination, (ii) direction it will be coming from and (iii) expected disturbance properties (e.g., 30 minutes, block two lanes, room for a compact car left, etc.).

[0088] In some embodiments, other local monitoring LTD application receivers (as well as

TMC, police operators, etc.) subscribed to the service are sent notifications if they are on the same route as the next destination of the truck, and if they will be affected by the blockage. [0089] In some embodiments, the LTD application queries vehicle sensors and makes a blockage calculation based on sensor reading, destination street/lane map and vehicle dimensions, and presents the findings to the user via an HMI. The user may review the analysis and send the warning data to local receivers. In some embodiments, local receivers receiving the warning evaluate if the warning is applicable to them based on their route, and if so provide alternate navigation. Local receivers, (e.g., the car following the truck or the car waiting at the traffic lights as shown in FIG. 4) may get the information from V2V or V2I communication and may adjust their route immediately. When delivery is over, the LTD application (or LTD server) may notify the LTD receiver and/or TMC backend server. Lastly, the delivery truck HMI is updated for the user.

[0090] In some embodiments, a method of providing local traffic blockage information includes the steps of sending a request for next destination address for a obstructing vehicle, receiving the location, delivery time, and estimated duration of a traffic blockage, sending a current traffic situation request for the delivery location, receiving estimated traffic volume, sending an information request to vehicle sensors, calculating blockage information based on the vehicle sensor information and known vehicle dimensions and displaying it to the user, sending a warning about the traffic disturbance to subscribed and local parties (e.g., TMC, police operators), other local vehicles via V2V and V2I for them to be re-routed, sending a disturbance cancellation warning when the delivery is completed, and displaying the cancellation to the users via an HMI.

[0091] In some embodiments, a method of providing local traffic blockage information includes the steps of receiving information about a destination of a vehicle and expected time of arrival, determining information about a road blockage based at least in part on road width at the destination and width of vehicle, in response to determination that there will be road blockage disruption, and computing routes for other vehicles such that the road blockage is avoided.

[0092] FIG. 10 illustrates a sequence diagram, in accordance with some embodiments. As shown, an LTD server obtains information 1002 including a scheduled stop location of a first vehicle, a predicted time during which the first vehicle is predicted to be at the stop location, a width of the first vehicle, and a road dimension at the stop location, and information 1004 including an initial route of a second vehicle and a width of the second vehicle, wherein the initial route passes the stop location during the predicted time. Based on the road dimension and the width of the first and second vehicles, the server determines through blocking rate calculation 1006, whether the first vehicle would block passage of the second vehicle, and in response to a determination that the first vehicle would block passage of the second vehicle, the server computes an alternate route 1008 for the second vehicle.

[0093] In some embodiments, the server transmits the alternative route 1010 to the second vehicle, which may then update the HMI and current navigation 1012. In some embodiments, the server also provides an alert to a driver of the second vehicle in response to a determination that the first vehicle would block passage of the second vehicle.

[0094] In some embodiments, determining whether the first vehicle would block passage of the second vehicle includes calculating available road space based on the width of the first vehicle and the road dimension at the stop location, and comparing the available road space to the width of the second vehicle.

[0095] In some embodiments, the scheduled stop location and predicted time are received from the first vehicle, as shown in FIG. 10. Similarly, the initial route of the second vehicle is received from the second vehicle.

[0096] While FIG. 10 illustrates the obtained information being received from the first and second vehicles, in some embodiments, a subset of the information is known within the server, through various databases. For example, in some embodiments, the widths of the first and second vehicle are obtained from a vehicle database (either within or in communication with the server), and the server receives vehicle identification information to search the database from the first and second vehicles. The vehicle identification information may include, but is not limited to, a make, model, and year of a vehicle. In some embodiments, the scheduled stop location and predicted time are obtained from a fleet management service in communication with the server. In some embodiments, the road dimension at the stop location is obtained from a map database in communication with the server. In some embodiments, the road dimension comprises a width of a traffic lane in the road. Alternatively, the road dimension information may include widths of bike lanes and sidewalks. In such embodiments, road users using mobile phones as navigation devices may receive alternate routes calculated by the server.

[0097] In some embodiments, the LTD server includes a non-transitory computer readable medium for carrying one or more instructions for performing the above steps. In some embodiments, the LTD server contains one or more of the databases, while alternatively the LTD server may be in communication with such databases.

[0098] In a first use case, John is driving a delivery truck in a city and is approaching his next destination. When he makes the final turn to the destination street, the in-vehicle system activates and sends a temporary road blocking pre-warning (for a block duration of 7 minutes) to other local road users. He reaches the next destination address, and there is no place to park the truck. Therefore, he stops the vehicle partly on the bike lane and traffic lane to unload the delivery. He can see from the in-vehicle system (HMI) which lanes are now blocked by his vehicle, and how much each lane is blocked e.g., as a percentage or measurement. He parks the truck against the curb to reduce the blocking of the traffic lane (vehicle lane). He sees via the in- vehicle system that the bike lane is fully blocked and that the traffic lane is partly blocked. Due to on-coming traffic in the street is frequent and passing may be difficult. The vehicle system indicates a percentage of how much the truck is blocking the lanes and which type of vehicles (traffic lane: smaller than mini-cars, bike lane: blocked, pedestrians: not affected) are able to pass his truck. He turns off engine and the HMI indicates that an updated warning has been shared to other local road users during the unloading. He can now perform the delivery without angry drivers in a traffic jam behind the truck. After the delivery is done he starts the engine and while driving towards the next destination, the in-vehicle system indicates that the temporary road blocking warning has been cleared.

[0099] Monica is driving a moderately sized car (sedan, small SUV) in the city. While approaching her next turn, she gets a warning that there will be a temporary road block for 7 minutes starting soon on the street she is going to turn right onto. The temporary road block will prevent her car from passing. The car navigator advises her in advance to instead continue straight to the next intersection to turn right, and Monica drives to her destination without any delays (See FIG. 9B).

[0100] Tracy is leading a nursery visit to a museum in the city with 35 young children. When the visit is about to end she learns from her mobile device that the bus they are to board is parked 50 meters from the museum entrance. The mobile application on her mobile device suggests sending out a warning to other road users about the group of children walking from the museum to the bus. She accepts and a local warning is sent via V2X from her mobile device to other local road users. Pedestrians approaching this location will receive a warning that the sidewalk between the museum entrance and the bus will be busy for next 10 minutes. Her mobile device HMI also indicates that nearby police are also informed about the situation. Another use case is illustrated in FIG. 9C, in which a user is warned on a mobile device of a partial road blockage caused by a fruit delivery. In the embodiment of FIG. 9C, the user is informed that her vehicle will be unable to pass in a northbound direction but that her vehicle may pass in a southbound direction.

[0101] FIG. 1 depicts an example client device that may be used as, for example, a primary terminal operating a traffic disturbance application. In particular, FIG. 1 is a system diagram of an example client device 102. As shown in FIG. 1, the client device 102 may include a processor 118, a transceiver 120, a transmit/receive element 122, a speaker/microphone 124, a keypad 126, a display/touchpad 128, a non-removable memory 130, a removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and other peripherals 138. The components illustrated with respect to the client device of FIG. 1 may also be used in the implementation of a server, such as a navigation server.

[0102] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Array (FPGAs) circuits, any other type of integrated circuit (IC), a state machine, and the like. The processor 118 may perform signal coding, data processing, power control, input/output processing, and/or any other functionality that enables the client device 102 to operate in a wired or wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit/receive element 122. While FIG. 1 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.

[0103] The transmit/receive element 122 may be configured to transmit signals to, or receive signals from, a base station over the air interface 115/116/117 or communication link 119. In some embodiments, transmit/receive element 122 may communicate directly with other client devices similar to 102. 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. In yet another embodiment, the transmit/receive element may be a wired communication port, such as an Ethernet port. It will be appreciated that the transmit/receive element 122 may be configured to transmit and/or receive any combination of wired or wireless signals.

[0104] In addition, although the transmit/receive element 122 is depicted in FIG. 1 as a single element, the client device 102 may include any number of transmit/receive elements 122. More specifically, the client device 102 may employ MTMO technology. Thus, in one embodiment, the client device 102 may include two or more transmit/receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 115/116/117. [0105] 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 client device 102 may have multi-mode capabilities. Thus, the transceiver 120 may include multiple transceivers for enabling the client device 102 to communicate via multiple RATs, such as UTRA and IEEE 802.11, as examples. In some embodiments, the client device 102 communicates via V2X communication protocols. In some embodiments, the client device 102 communicates with a similar client device using V2V communications, while the client device 102 may also communicate with roadside units (RSUs) via V2I communication. Client device 102 may share information such as sensor information with other vehicles/devices in the area via the V2X communication protocol. One or more modules for vehicle-to-vehicle (V2V) or vehicle-to-infrastructure (V2I) communication may also communicate with the processor. The V2V and/or V2I module may be for dedicated short range communications (DSRC), wireless access in vehicular environment (WAVE), WiFi, or other like wireless communication enabling V2V or V2I communication. The V2V and/or V2I module may be transceivers that enable two-way short to medium range (e.g., up to 1000 meters) wireless communication capabilities. In an exemplary embodiment, the dedicated short range communication works on a 5.9 GHz band with bandwidth of 75 MHz. In addition to being onboard in a vehicle, enabling vehicle to vehicle (V2V) communication with other capable vehicles, nodes may also be roadside units (RSUs) enabling vehicle to infrastructure (V2I) communication. A vehicle may exchange information with one or more other vehicles such as information obtained from one or more interior sensors, one or more exterior sensors, or one or more other modules (e.g., and without limitation, a GPS module). The messages received during a V2V or V2I exchange are typically transmitted within the vehicle over a vehicle network.

[0106] The processor 118 of the client device 102 may be coupled to, and may receive user input data from, the speaker/microphone 124, the keypad 126, and/or the display/touchpad 128 (e.g., a liquid crystal display (LCD) display unit or organic light-emitting diode (OLED) display unit). The processor 118 may also output user data to the speaker/microphone 124, the keypad 126, and/or the display/touchpad 128. In addition, the processor 118 may access information from, and store data in, any type of suitable memory, such as the non-removable memory 130 and/or the removable memory 132. The non-removable memory 130 may include random-access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like. In other embodiments, the processor 118 may access information from, and store data in, memory that is not physically located on the client device 102, such as on a server or a home computer (not shown).

[0107] 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 client device 102. The power source 134 may be any suitable device for powering the client device 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, a wall outlet and the like.

[0108] 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 client device 102. In addition to, or in lieu of, the information from the GPS chipset 136, the client device 102 may receive location information over the air interface 115/116/117 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 client device 102 may acquire location information by way of any suitable location-determination method while remaining consistent with an embodiment. In accordance with an embodiment, the client device 102 does not comprise a GPS chipset and does not acquire location information.

[0109] The processor 118 may further be coupled to other peripherals 138, which may include one or more software and/or hardware modules that provide additional features, functionality and/or wired or wireless connectivity. For example, the peripherals 138 may include an accelerometer, an e-compass, a satellite transceiver, a digital camera (for photographs or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, and the like. In some embodiments, the processor 118 communicates with one or more of the peripherals 138 using a vehicle controller area network (CAN) bus.

[0110] 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 media include electronic signals (transmitted over wired or wireless connections) and computer- readable storage media. 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 client device, UE, terminal, base station, RNC, or any host computer.

Claims

CLAIMS We claim:

1. A method comprising:

obtaining information comprising a scheduled stop location of a first vehicle, a predicted time during which the first vehicle is predicted to be at the stop location, a width of the first vehicle, and a road dimension at the stop location;

obtaining information comprising an initial route of a second vehicle and a width of the second vehicle, wherein the initial route passes the stop location during the predicted time;

based on the road dimension and the width of the first and second vehicles, determining whether the first vehicle would block passage of the second vehicle; and

in response to a determination that the first vehicle would block passage of the second vehicle, computing an alternate route for the second vehicle.

2. The method of claim 1, further comprising transmitting the alternative route to the second vehicle.

3. The method of claims 1 or 2, further comprising providing an alert to a driver of the second vehicle in response to a determination that the first vehicle would block passage of the second vehicle.

4. The method as in any of claims 1-3, wherein determining the first vehicle would block passage of the second vehicle comprises calculating available road space based on the width of the first vehicle and the road dimension at the stop location, and comparing the available road space to the width of the second vehicle.

5. The method as in any of claims 1-4, wherein the widths of the first and second vehicle are obtained from a vehicle database, and wherein the method further comprises receiving vehicle identification information to search the database from the first and second vehicles.

6. The method as in any of claims 1-5, wherein the scheduled stop location and predicted time are obtained from a fleet management service.

7. The method as in any of claims 1 -5, wherein the scheduled stop location and predicted time are received from the first vehicle.

8. The method as in any of claims 1-7, wherein the initial route of the second vehicle is received from the second vehicle.

9. The method as in any of claims 1-8, wherein the road dimension at the stop location is obtained from a map database.

10. The method as in any of claims 1-9, wherein the road dimension comprises a width of a traffic lane in the road.

11. A server including a non-transitory computer readable medium for carrying one or more instructions, wherein the one or more instructions, when executed by one or more processors, causes the one or more processors to perform the steps of:

obtaining information comprising a scheduled stop location of a first vehicle, a predicted time during which the first vehicle is predicted to be at the stop location, a width of the first vehicle, and a road dimension at the stop location;

obtaining information comprising an initial route of a second vehicle and a width of the second vehicle, wherein the initial route passes the stop location during the predicted time;

based on the road dimension and the width of the first and second vehicles, determining whether the first vehicle would block passage of the second vehicle; and in response to a determination that the first vehicle would block passage of the second vehicle, computing an alternate route for the second vehicle.

12. The server of claim 11, further comprising instructions for transmitting the alternative route to the second vehicle.

13. The server of claim 11 or 12, further comprising instructions for providing an alert to a driver of the second vehicle in response to a determination that the first vehicle would block passage of the second vehicle.

14. The server as in any of claims 11-13, wherein the instructions for determining the first vehicle would block passage of the second vehicle comprise calculating available road space based on the width of the first vehicle and the road dimension at the stop location, and comparing the available road space to the width of the second vehicle

15. The server as in any of claims 11-14, further comprising instructions for receiving vehicle identification information from the first and second vehicles, the vehicle identification information used to search a vehicle database to obtain the widths of the first and second vehicle.

16. The server as in any of claims 11-15, wherein the scheduled stop location and predicted time are obtained from a fleet management service.

17. The server as in any of claims 11-15, wherein the scheduled stop location and predicted time are received from the first vehicle.

18. The server as in any of claims 11-17, further comprising instructions for receiving the initial route of the second vehicle from the second vehicle.

19. The server as in any of claims 11-18, wherein the road dimension at the stop location is obtained from a map database.

20. The server as in any of claims 11-19, wherein the road dimension comprises a width of a traffic lane in the road.