HK1136867A - Navigation device assisting road traffic congestion management - Google Patents

Abstract

A navigation device has a GPRS receiver for receiving real-time information about slow traffic flow or slow average speed on a stretch of motorway, indicating congestion. The device calculates a new itinerary to avoid the congestion, based on historically recorded speeds on secondary roads weighed by the current average speed in the congestion area.

Description

Navigation device for assisting road traffic jam management

Technical Field

The present invention relates to a mobile electronic navigation device, software for implementing the functionality of the device and a method of providing services to a user of such a device.

Background

Advances in technology and the ever-increasing pressure of congested road environments have driven the development and adoption of Personal Navigation Devices (PNDs). The abbreviation PND is sometimes used to refer to "portable navigation device", but will be given its broader definition in this specification: it encompasses any kind of personal navigation device, either portable (e.g. fixable to a car windscreen using a suction mount) or embedded (e.g. permanently fixed into a car). The PND may be a dedicated navigation device (e.g. a device whose primary function is navigation) or may have multiple other applications (e.g. media players) or may have a primary function other than navigation (e.g. a mobile phone). PNDs are used primarily (but not exclusively) in automobiles and other motor vehicles. The PND incorporates a map database including road information and points of interest. It generally comprises software for performing the following operations: allowing a user to input a destination and providing the user with one or more paths; a driving instruction is issued to guide the driver along the selected path to the destination. The PND may comprise a mount attachable to the windscreen of the vehicle.

The selection of a route along which to guide the driver may be very complex, and the selected route may take into account existing and predicted traffic and road conditions, historical information regarding road speeds, and the driver's own preferences as factors in determining road selection. In addition, the device may constantly monitor road and traffic conditions and propose or choose to change the path on which the remainder of the journey is made as a result of a change in conditions.

Road travel is an important part of the daily life of businesses, other organizations, and private individuals. The cost of traffic delay can be significant. In the uk alone, the purely financial cost has been estimated as billions of pounds. In view of these costs, a system that can assist the driver in optimizing their travel, for example by selecting the best path and by avoiding congestion delays, is of significant value. In fact, a large variety of driver information systems have gradually been formed. The earliest established was a broadcast radio traffic report that aggregated data from multiple sources such as police, scout satellites, and (more recently) mobile phone calls from drivers stuck in traffic jams to provide subjective advice about accidents and delays. Radio Data System (RDS) radios make these systems more efficient by automatically switching from normal radio programming to traffic reports. A static path planning system is provided on the website of large automobile transportation organizations (e.g., the Automobile Association (AA) and RAC in the uk). These static path planning systems allow the driver to enter a trip point and provide the driver with a path and driving instructions for that path.

In the recent past, in-vehicle personal navigation devices have been introduced based on Global Positioning System (GPS) technology. An example of these in-vehicle personal navigation devices is TomTom GO^TMA series of PNDs. Personal navigation devices use the GPS system to find the exact location of the vehicle on the road network and plot the location of the vehicle on a road map on a screen. PNDs contain mechanisms for calculating the best or good path between two or more points on a road network and can direct the driver along a selected path and constantly monitor the driver's position on that path. Personal navigation devices have begun to incorporate traffic information into their services, and in some devicesIntegrating traffic information into a route selection process: the PND will route around the congested road. In the case where traffic information is provided by the PND, the user may observe delays affecting the selected route, and direct the device to re-plan a route that avoids the delayed portion of the road, as the user deems necessary. Real-time traffic monitoring systems based on various technologies (e.g., mobile phone calls, fixed cameras, GPS fleet tracking) are being used to identify traffic delays and to feed information into notification systems.

As mentioned above, road traffic can be monitored in real time on the basis of mobile phone calls as follows. In a mobile telephone system, a subscriber carries a handset. When a subscriber initiates or receives a call or text message or data session, radio communication occurs between the handset and a Base Transceiver Station (BTS), a familiar transmit antenna on modern landscapes. The handset and BTS transmit both the encoding of messages passed between the calling party and the called party and also transmit a large amount of control information between themselves for the purpose of reliably and efficiently supporting communications; for example, as the subscriber moves around, the system must select when to transfer the call to another BTS. Control information in a global system for mobile communications (GSM) system or in a Universal Mobile Telecommunications System (UMTS) contains information about the signal strength of neighboring BTSs, timing advance information to instruct handsets further away from the BTS to transmit earlier in order to match their time slots, transmission error rates, and more. Other technologies, such as Code Division Multiple Access (CDMA), use different information to achieve the same goal of reliable and efficient communication. These parameters are collectively referred to as mobile phone control parameters. A Location Parameter Database (LPDB) relates mobile phone control parameters to the geographical location of the handset. The LPDB may be constructed and maintained in one of several ways, and one of several useful subsets of control parameters may be mapped to a geographic location.

More background information on the PND and the above services, see, for example, U.S. patent application publication US 20070225902; US 20070185648; US 20070118281; and US 20070117572, all of which patent application publications are owned by tomtomtom International b.v. and incorporated herein by reference.

More background information on monitoring road Traffic by monitoring the use of mobile telecommunication devices carried on road vehicles, see for example WO200245046 ("Traffic monitoring system"); and WO2007017691 ("Method of finding the physical location of a mobile phone at a given time"), which is incorporated herein by reference.

Disclosure of Invention

The inventors aimed to improve the navigation guidance for individual users of road vehicles. The inventors further intend to improve traffic management in order to avoid or reduce traffic congestion.

The invention relates inter alia to a mobile electronic navigation device configured for providing navigation information to a mobile user on a road network in dependence on the geographical position of the device, and upon being programmed to guide the mobile user to a predetermined destination via a route. The device includes: storage means for storing information (e.g. road map information) about segments of a road network, the information comprising historical data representing respective historical traffic progress (e.g. average speed or average traffic flow) on respective ones of the segments; a wireless receiver for receiving data indicative of current traffic progress (e.g., current average speed or current traffic flow) on a road segment of a particular road in the section; and a data processor coupled to the receiver. The processor is further operative to perform the following tasks. The processor determines whether the segment is included in a portion of the route that is still to be traveled. Determining navigation guidance using the route if the processor has determined that the road segment is not included. If the processor has determined that the road segment is included, the processor uses the historical data to determine an alternate route to the destination based on comparing a first expected travel time of the route to a second expected travel time of the alternate route given the current traffic progress. Depending on the result of the comparison, the processor begins to provide navigation information regarding the alternate route.

Thus, upon receiving real-time information about current traffic progress on road segments in the upcoming branch of the original route, which may indicate that the alternative route has a shorter expected travel time, the navigation device in the present invention provides navigation guidance according to the alternative route. The data received via the receiver may indicate a newly occurring or existing traffic jam in the upcoming leg of the trip. The device in the present invention then searches for an alternative route to the original route for the portion to be traveled. If the traffic jam has disappeared before the user must be guided according to the alternative route, the receiver receives data indicative of improved traffic progress (e.g., increased traffic flow or increased average speed) on the road segment and the device similarly determines that the original route will be considered the basis for guidance.

In an embodiment of the device in the invention, the second expected travel time is calculated based on scaling the historical traffic progress (e.g. average speed or average traffic flow) on another link in the alternative route by a quantity representative of the current traffic progress (current average speed or current traffic flow) on the particular link. The scaling is due to the fact that congestion on one road may result in more congested traffic on the connecting road. That is, congestion affects nearby traffic flow and average speed. By taking this phenomenon into account by scaling, an alternative path is calculated that more reliably approaches the shortest total travel time to the destination.

In addition to current traffic progress conditions, current or predicted weather conditions may also affect travel time, or more generally, routes. Thus, when calculating the modification to the current route, it is preferred to also take into account real-time information about weather conditions. For the purpose of the present invention, weather conditions such as fog, rain, snow, black ice, etc. may be translated into quantities representing the (virtual) traffic progress. In the case of dangerous road conditions due to bad weather, the predicted travel time of the weather-affected road segments covering the route is scaled up. The scaling factor may be determined, for example, based on historical data (see historical data extracted further from the GPS track below) or may be determined experimentally or roughly estimated. This proportional increase in travel time, regardless of origin, whether from traffic congestion or from dangerous road conditions, is a quantity considered in the data processing in the present invention. Thus, for the purposes of the present invention, the concept "current traffic progress" is also understood herein to encompass "current or predicted weather conditions".

Another embodiment of the invention relates to software for a mobile navigation device configured for providing navigation information to a mobile user on a road network depending on the geographic location of the device, and upon being programmed to guide the mobile user to a predetermined destination via a route. The device includes: storage means for storing information about segments of a road network, the information comprising historical data representing respective historical traffic progress on respective ones of the segments; a wireless receiver for receiving data indicative of current traffic progress on a segment of a particular road in the section; and a data processor coupled to the receiver. The software includes instructions for controlling the processor to: determining whether the segment is included in a portion of a route to be traveled; if the road segment is not included, continuing to use the route; if the road segment is included, using historical data to determine an alternative route to the destination based on comparing a first expected travel time of the route to a second expected travel time of the alternative route given current traffic progress; depending on the result of the comparison, navigation information regarding the alternative route is started to be provided. Preferably, the software contains further instructions for the processor to: the second expected travel time is calculated based on scaling historical traffic progress on another road in the alternate route by an amount representative of current traffic progress on the particular road.

Thus, the software may be provided as an after-market add-on (after-market add-on) or as an upgrade to the installation base of an electronic navigation device having a wireless receiver. A separate wireless receiver may optionally be mounted to a conventional electronic navigation device in order to use the service enabled by the provisioning data representing real-time traffic conditions as specified above.

The wireless receivers introduced above include, for example, General Packet Radio Service (GPRS) receivers. As is known, GPRS is a packet-oriented mobile data service available to users of GSM mobile phones. The word "packet-oriented" refers to the manner in which data packets are multiplexed. GPRS data communications may be unidirectional or bidirectional. Alternatively, the radio receiver comprises a Radio Data System (RDS) receiver. RDS technology uses conventional FM radio broadcasts to transmit data. RDS technology is commonly used to implement a Traffic Message Channel (TMC) for communicating traffic information to drivers. Other implementations of wireless receivers are based, for example, on Digital Audio Broadcasting (DAB) technology or satellite radio, the latter using communication satellites covering a larger geographical area than the geographical area covered by transmissions using terrestrial technology.

GPRS technology enables two-way data communication. This may be used in an embodiment of the invention where the PND has a GPRS receiver and a GPRS transmitter, and where the PND is configured as a thin-client (thin-client) that delegates the calculation and/or re-calculation of routes to predetermined destinations to a server.

The inventors therefore further propose a method of providing navigation information to a user of a mobile navigation device in dependence on the geographical location of the device for guiding the user to a predetermined destination via a route. The method comprises the following steps. Data representative of a geographic location is received from the device. With the current geographical position of the device known, a section of the road network relating to the route is determined. Determining information about the section, the information comprising historical data representing respective historical traffic progress on respective roads in the section. A current traffic progress of traffic on a segment of a particular road in the section is determined. It is then determined whether the segment is included in a portion of the route to be traveled. If the road segment is not included, the route is used. If the road segment is included, historical data is used to determine an alternative route to the destination based on comparing a first expected travel time of the route to a second expected travel time of the alternative route given the current traffic progress. Depending on the result of the comparison, navigation information is provided regarding the alternative route.

Preferably, the second expected travel time is calculated based on scaling the historical traffic progress on another road in the alternative route by an amount representative of the current traffic progress on the particular road.

The advantage of a lightweight client approach or delegating processing to the server lies in the fact that: the server has available traffic information and weather information for a plurality of geographic regions including the region in which the user is heading. This enables a route to be dynamically optimized on a scale larger than that which is only locally within a single one of the geographic regions.

Drawings

The invention is explained in more detail by way of example and with reference to the accompanying drawings, in which:

FIG. 1 is a block diagram of a system in the present invention;

FIGS. 2 and 3 provide formulas to explain aspects of the present invention;

FIG. 4 is a block diagram of a first example of a navigation device in the present invention;

figures 5 and 6 are block diagrams of other examples of navigation devices in the present invention; and

fig. 7 is a flow chart of a method of providing navigation guidance to a user of the device of fig. 5 and 6.

Throughout the figures, similar or corresponding features are indicated by the same reference numerals.

Detailed Description

According to some studies, approximately 25% of the traffic monitored on a particular road or highway is made up of vehicles driving longer, inter-regional paths. This is a significant group that can very easily take alternative routes to a particular road or highway. The problem is how to inform the alternate path? The authorities may inform all drivers driving in the area north of Amsterdam (Amsterdam) city of: if it is intended to go to freveland (Flevoland) or beyond, it is today best to use the enkhuaze-leiston (Enkhuizen-Lelystad) embankment. Drivers from the armsterfin (Amstelveen)/schiphone (Schiphol) area may be advised to drive via the city of the british branch (urtrecht). However, it is extremely difficult to inform these drivers, or even more, in order to convince them that they should adopt the advice. The driver needs more detailed information in order to be able to accept the alternative route.

The system in the present invention proposes an alternative path to the driver via a mobile navigation device carried on the driver's vehicle. In addition to proposing alternative routes, the expected advantages of employing these alternative routes are also clarified. Thus, when traffic congestion occurs in a particular geographical area, the system of the present invention suggests that a driver driving within or traveling towards this area proceed according to the directions currently being provided via the mobile navigation device in order to automatically avoid the congestion. The system of the present invention thus helps the driver to reach his destination earlier. Furthermore, the system also helps to reduce the traffic through the congested area by spreading the traffic over the rest of the road network in the vicinity of the congested area.

It has been demonstrated that most cars in traffic jams are traveling in short zones. An example of a driver making an in-zone trip is a person who lives in the town of Almere (Almere) who intends to shop in a city near amsterdam. The system of the present invention is able to inform these drivers of the predicted travel time before they start their journey. If delays due to traffic congestion are expected, these people may want to reconsider their journey. It may decide to instead shop locally, drive to another town or city, or take one of the proposed alternative routes or use public transportation. Also, the amount of traffic through the congested area will be reduced.

There is always a group of drivers who decide to enter the congested area despite congestion. People often misunderstand that driving through small rural and urban centers instead in such situations in order to bypass congestion is an acceptable solution. Studies have confirmed that this drive is completely ineffective. This occurs, inter alia, because the maximum allowed road speed is low and the average speed achievable is not higher than 15km/hr to 25km/hr due to traffic lights and non-active routes. In most cases, the driver's destination is reached faster by staying only on traffic jams or using regional roads. All devices from the current assignee tomtomtom use these fastest path settings by default in order to avoid guidance via invalid paths. However, the lack of reliable up-to-date travel time information makes people find their way but ineffective. The system of the present invention is intended to persuade these people to receive navigation information for their own benefit.

Thus, the system of the present invention provides more reliable and effective guidance for a moving person. Based on an excellent travel time estimate, one can consider and more readily accept alternative paths. The system of the present invention improves the utilization of the primary road network and helps to reduce traffic congestion. Drivers who are making inter-regional trips are rerouted to bypass the congested area. Regional drivers will be advised to use regional alternative routes or to accept delays caused by congestion.

The system of the present invention produces high quality traffic information for the entire road network. The system can propose alternative paths that better utilize the available road network around congested areas. The system uses a multi-source strategy. The system combines traffic information from existing sources, such as supplied by road authorities and other public services, with traffic information generated based on data supplied by mobile telephone network operators and with traffic information supplied by users of GPS-enabled mobile navigation devices. Thus, a detailed overview of the bottleneck of the jam is created. This detailed summary may then be used to generate navigation information regarding the alternate path.

Fig. 1 is a block diagram of a system 100 in the present invention. The system 100 includes a data collection and acquisition subsystem 102 that receives data from transportation departments, road operators or road authorities, local governments, and the like (all of which are referred to herein as "authorities" 104), data from a mobile telephone network operator 106, and data from a user of a GPS-enabled mobile navigation device 108.

The data received from the authorities 104 represents, for example, conventional traffic information obtained via wayside traffic monitoring devices. The apparatus includes, for example, a live camera and other road sensors such as inductive loops integrated in the road surface. Other data received from the authorities 104 may include road engineering reports. Still other data received from authorities 104 includes, for example, weather forecasts or real-time weather radar data. Real-time weather radar data can scale up, for example, expected travel times on roads in areas with large amounts of rainfall, with reduced visibility due to fog or light rain, or with strong gusts of wind, to account for slower traffic.

The data received from operator 106 represents road traffic monitored in real time on the basis of mobile phone calls as explained above and in, for example, WO200245046 and WO2007017691 mentioned above.

The data received from the user of the GPS-enabled mobile device 108 is based on the following. The device 108 is configured for recording GPS tracks. When the device 108 is in operational use, the device 108 repeatedly records its geographic location and timestamp in a file. The record in the file enables to reconstruct the journey taken with this particular device. An example of such a device 108 is made by the present assignee. The device 108 cooperates with a software program ("TomTom Home") installed on the user's Home PC or laptop PC. The software program enables the user to update, personalize, and otherwise manage the device 108. For example, if the user wants to install a new map, a customized point of interest database, or have the device 108 provide directions in another voice, the user may simply download these and other components from a server via the Internet and install them on the device 108. The program also allows for the pre-planning of an individual's itinerary from home. When connected to the server, the server will upload the recorded files. Records are collected from all devices 108 and stored in subsystem 102.

Thus, the system 100 has real-time data available through the mobile phone network operator 106 and historical data available through downloading of GPS traces. These data are now processed in data processing subsystem 110 for generating traffic information stored in storage device 114.

The data processing subsystem 110 processes the historical data (e.g., represented by the GPS traces from the devices 108) to generate traffic information that includes, for purposes of the present invention, the average speed of roads that are not (or are not adequately) covered by real-time data from the operator 106. To explain the process, consider the following scenario.

Consider the situation at a backbone path that bypasses an urban environment. This urban environment may be a small town bypassed by a national motorway or a heavily used major urban road surrounding a large city or traversing suburbs or city centers. When the backbone path is not blocked, the GSM-based data received from operator 106 and the GPS-based data received from device 108 indicate normal travel times on the primary road. But during peak hours, the travel time may increase dramatically. The data received from operator 106 and device 108 indicates this increase in travel time during peak hours. An increase in travel time corresponds to a decrease in average link speed. For example, the average speed is typically between about 100km/hr and 120km/h, but during peak hours the average speed is about 30 km/h. During peak hours, the average speed on the urban network of secondary roads also decreases, for example, from about 35km/h to about 15 km/h. Real-time data received from operator 106 cannot reliably measure real-time travel time on smaller roads in urban areas due to low traffic volumes; especially due to the high traffic volume, only travel times measured on urban trunks are available. Thus, if the user's mobile navigation device does not take into account these varying average link speeds on the secondary link, it may cause the user to enter into congested or slow moving traffic on the secondary link, as these are not associated with an average speed of 15km/hr during rush hour, but are erroneously associated with a static average speed of 35km/hr, which is still 30km/hr faster than the current average speed on the congested trunk path.

To improve the navigation guidance for the driver, the inventors therefore propose to use both GSM-based real-time data and GPS-based historical data in order to provide an estimate of the average speed or travel time on the secondary road, as explained in further detail below.

Consider now the following scenario. System 100 determines whether a particular road segment of a particular motorway is congested via, for example, data from operator 106. That is, the average speed on this link is significantly lower than during normal traffic flow. It seems reasonable to assume that congestion also affects the average speed on secondary roads leading to a congested stretch of motorway or leaving a congested stretch of motorway. The traffic information generated and stored as data in the storage 112 relates to the average speed on a congested road segment and/or the predicted travel time to cover this road segment under the current circumstances. This data is sent via the server 114 to users of electronic navigation devices 118 in the relevant geographical area via a data network 116 comprising a GPRS infrastructure. GPRS is a known technology that is capable of receiving data packets via a mobile data service available to users of GSM mobile phones. As mentioned above, data may be communicated from server 114 to device 118 using wireless data communication technologies other than GPRS. GPRS is mentioned here as a practical example. It is also noted that in addition to traffic information regarding the current average speed on the roads under consideration, the server 114 may also communicate data to the device 118 that is representative of weather conditions that are present or anticipated in the relevant geographic area. The data may refer to, for example, strong gusts of wind, fog, black ice, and so forth. Device 118 is preferably configured to process this data to generate information that is communicated to a user of device 118 via its display monitor and/or speaker.

The navigation device 118 is configured to process this data as follows and as explained in more detail below. Given the destinations of one or more users of device 118 and given the user's original route first calculated by device 118, congestion may affect the user's travel time. With the speed on the congested motorway segment known, the device 118 now recalculates the route by taking into account the predicted speed or travel time on the secondary roads in the congested area. To this end, the device 118 makes available the required information, for example from its local storage. Device 118 can thus make an educated guess as to which paths to take for the detour in order to optimize, for example, travel time in the presence of traffic congestion ahead.

The details of the method employed are as follows. The inventors introduced the concept of virtual real-time speed (VRS). In one embodiment of the invention, the VRS is calculated within the PND in situations where real-time data is not available for the relevant road. Calculating a VRS based on historical average speed information for the road. The VRS of secondary road sections in a particular geographic area having traffic affected by congestion on a primary motorway or primary trunk path in the area is calculated. The VRS is determined by the speed of real-time traffic on the primary motorway. In some circumstances, it is assumed that the VRS on the secondary road depends on the real-time speed on the adjacent primary motorway. The present invention now takes advantage of this correlation to improve the accuracy of the navigation guidance for the individual user of device 118.

Several methods can be employed to determine VRS: line-based methods and zone-based methods, as explained in detail below. Preferably, a zone-based VRS is used. However, in the case where the area-based VRS cannot be calculated, the line-based method is used.

The process for the line-based approach proceeds as follows. Real-time speed on a portion of the motorway concerned determined from GSM-based data has a value V_real-mot. The historical average velocity over this portion determined from the GPS trajectory has a value V_hist-mot. Now consider a road section in a road network surrounding the portion of the motorway. For this section labeled "i", function F is used, for example, by means of expression (202) according to fig. 2_lineScaling the historical average velocity V of the segment_i，hist-segAnd assigns a value V to VRS_i，VRS-seg. Determining a historical average velocity V of the section based on the GPS trajectory mentioned above_i，hist-seg. The scaling function F is according to expression (204) in FIG. 2_lineDependent on the first quantity V_{real-mot-line}And a second quantity V_{hist-mot-line}. The first quantity V is expressed according to expression (206)_{real-mot-line}Defined as the average of real-time speed measured from GSM-based data over N sections of the relevant motorway. The portions are identified, for example, on the basis of Traffic Message Channel (TMC) codes as known in the art. Second quantity V is expressed according to expression (208)_{hist-mot-line}Defined as the average of historical speeds recorded from the GPS track over N sections of the relevant motorway. An example of a scale factor F that may be used is provided in expression (210) of fig. 2, but other correlations are possible. For expression (202), expression (210) implies that V is assumed_i，VRS-segAnd V_{real-mot-line}Is equal to V_i，hist-segAnd V_{hist-mot-line}The ratio of (a) to (b). This is roughly interpreted as: it is assumed that the ratio of the number of vehicles currently present on the secondary road section "i" to the number of vehicles currently present on N portions of the motorway is equal to the ratio of the number of vehicles present on section "i" in the past according to the GPS track in the considered time window to the number of vehicles present on N portions of the motorway in the past in the same time window. That is, traffic on the secondary road is scaled according to traffic on the primary motorway.

The above examples of scale factors in expressions (202), (204) and (210) produce a relatively simple model, which, however, is actually useful in modeling traffic flow for purposes of the present invention. The scale factor represents the phenomenon that congestion on motorways leads to slower speeds on connected secondary roads in adjacent parts of the road network. In general, the relationship between speed and traffic flow is a complex relationship, and many other quantities for modeling traffic flow may be considered in addition to speed, such as response time, acceleration and deceleration of individual vehicles, time derivatives of speed and/or traffic, position derivatives of speed and/or traffic, and so forth. Shock waves may be formed in the traffic flow, resulting in notorious traffic jams or link collisions. See, for example, G.B.Whitham, "Linear and Nonlinear Waves" ("Linear and Nonlinear Waves") Chapter 3.1, "Traffic flow" ("Traffic Flows") (Wiley-Interscience 1999).

Instead of using expression (202), one can use, for example, for quantity V_i，VRS-segFor example a set of two values, where one preset value represents normal speed (when the corresponding main motorway is not congested) and the other preset value represents flow in case of a congested main motorway. The latter value may be determined by scaling the normal speed by a factor representing the real-time speed at the connected stretch of the congested motorway. Other correlations may be considered in order to determine a quantity representative of an expected travel time along a particular path, given historical data about the average speed and/or traffic volume of the path, while taking into account the impact of congestion on nearby roads.

The scaling factor of expression (210) uses the ratio of speeds. Alternatively, the scale factor M may be used with expression (202)_lineScale factor M_lineIncluding the first quantity TF provided in expression (212)_{real-mot-line}And a second quantity TFhist_-mot-lineThe ratio of (a) to (b). The first quantity TF_{real-mot-line}Defined as passage over one or more parts of the relevant motorway:for example) the average of real-time traffic flow (i.e., the number of vehicles passing a location per unit time) measured by loop sensors in the road surface. Second quantity TF_{hist-mot-line}Defined as the average of historical traffic flow on the one or more portions of the relevant motorway.

Note that the historical data considered in these calculations should preferably have a time stamp in the time slot corresponding to the current time. For example, a VRS computed at the time of 17:00GMT on a certain Wednesday should take into account data from GPS traces generated at about the same time on the same day and also on past Wednesdays.

It has been shown that the line-based approach is less accurate than the zone-based approach. It is therefore preferred to use the line-based approach only when the region-based approach does produce a suitable VRS. The zone-based approach is discussed in detail below, followed by a description of a scenario in which the line-based approach should preferably be used.

The region-based approach proceeds as follows. The real-time speed on a section of a motorway is called V_real-motAnd is determined on the basis of GSM data. The historical average velocity over this portion is referred to as V_hist-motWhich is determined on the basis of the GPS track. Real-time speed V on motorway_real-motDown to a certain threshold level V_{real-mot-threshold}In the following (as an indication of a severe unusual blockage of the motorway), a zone-based virtual real-time speed is calculated.

A threshold factor G may be used_thresholdDeriving a threshold speed V from historical speed data_{real-mot-threshold}. Historical speed data has been stored in the speed profile for that particular motorway section in the storage device 102, and the threshold factor G must be determined experimentally_threshold. The above considerations regarding time stamps in the line-based approach also apply to the zone-based approach. Expression (302) of FIG. 3 conveys G_thresholdThe significance of (1). If V_real-motDown to threshold speed G_thresholdHereinafter, it is necessary to use the second stage in the area around the motorway portionVRS on the road.

This VRS calculation is similar to the VRS calculation discussed above under the line-based approach. However, now the scale factor H is calculated for regions rather than for lines_areaAssuming that sufficient real-time data is available for the roads in the zone. Calculating a scale factor H for each section of the motorway by dividing the average real-time speed of the roads in the concerned zone by the average historical speed of these roads for which the real-time speed is calculated_area. Real-time speed measurements extracted from GSM-based data supplied by operator 106 distinguish traffic traveling in one direction on a road from traffic traveling in another direction on the same road. See, for example, WO200245046 and WO2007017691, mentioned above.

Preferably, upon receipt of this real-time data by the navigation device 118, the device 118 only considers those measurements relating to traffic flow in those directions and on those roads that are in a routing corridor (routing corridor) from the user's current location towards a predetermined destination. Here, the routing channel is that portion of the road network around the congested area to be avoided, which contains a route as a candidate route for inclusion in the alternative route. A path in this sense is a directed graph. By taking into account routing channels, it is particularly prevented that traffic flowing into the direction opposite to the direction of travel of the user of the device 118 and on the same path is taken into account when determining detours. Thus, the scale factor H_areaGenerally depending on the intended destination.

Another difference is that: will scale according to the set of real-time measured speeds on the secondary road network rather than according to the set of real-time measured speeds on the motorway segment. The above is further explained as follows.

Expression (304) corresponds to expression (202) of fig. 2, except for the scaling factor. In accordance with a first quantity V in expression (306) of FIG. 3_real-areaAnd a second quantity V_hist-areaSpecifying a scale factor H_area. The first quantity V is expressed in expression (308)_real-areaDefined as being on a main road in a road network sectionAverage of all real-time speeds measured on secondary roads (j ═ 1.. multidot.m) around a jam on a road or motorway section. The second quantity V is expressed in expression (310)_hist-areaDefined as the average of all historical speeds measured on a secondary road (j 1...., M) around a congestion on a main road or motorway segment in a road network section. Preferably, as mentioned above, only those real-time speeds and historical speeds belonging to the routing channel are considered. As quantity V in expression (312)_real-areaAnd quantity V_hist-areaProviding a scaling factor H_areaA simple example of (a). As mentioned above under the line-based approach, other correlations can also be considered in the zone-based approach. Also, instead of making the scale factor H_areaBased on the measured speeds (real-time and historical), real-time traffic flow and historical traffic flow may instead be employed to determine the scaling factor H_area。

The above calculations and recalculations of routes have been described in the context of a user of device 118 being on a road and receiving updates via GPRS regarding traffic conditions ahead. A similar scenario may apply to a user who is still at home and plans his itinerary just prior to departure. The user now downloads the route onto his mobile navigation device 118 using the dedicated software 120 on his PC 124 (in fig. 1). Similarly, current and expected traffic conditions generate a particular route that is downloaded to the device 118 and may be dynamically changed again while the user is driving. In addition, relevant data provided by server 114 may be supplied to authorities 124 to enable responses to traffic situations. The authorities 124 may include those referrals under the authorities 104, but may also include personnel of ambulances, fire trucks, special road transport operators, railroad operators, bus operators, and so forth.

As mentioned above, the information collected in the storage 102 may also include information about current or predicted weather conditions (e.g., inferred from weather radar). Note that from a traffic flow perspective, dangerous weather may affect road conditions similar to traffic congestion. That is, the average speed achievable in fog, heavy rain, during a snow storm, or in the presence of black ice, will be lower than that achievable under more favorable weather conditions. In one embodiment of the invention, as described above, hazardous weather conditions may be mapped onto quantities representing equivalent traffic flows for purposes of calculating routes. That is, the device 118 interprets GPRS data as representing traffic flow conditions or average speed, while the data is directly derived from weather conditions.

To explain the use of traffic information generated in the system 100, the mobile navigation device 118 is considered in more detail. Reference is now made to fig. 4.

The navigation device 118 includes: a GPS receiver 402, a wireless receiver 404, a database 406 storing map information, a user control 412 to enable a user to control the device 120, a rendering subsystem 408, a track storage 410, and a data processor 414 executing under the control of software 416. The processor 414 is responsible for processing data and controlling the other components of the device 118 for the purpose of communicating navigation services to the user of the device 118. The wireless receiver 404 includes, for example, a GPRS modem.

The GPS receiver 402 is configured to determine the current geographic location of the device 118. The processor 414 uses the information regarding the current location to determine road maps and other location-related information relating to the user of the device 118 in the database 406 with the current location known. Knowing the destination of the trip and the road information from the map, the software 414 is able to generate and play out the navigation guidance via the rendering subsystem 408. As in conventional mobile navigation devices, the user enters destination and other control information (e.g., preferences regarding playing out guidance information via the user controls 412, preferences for avoiding motorways, etc.). The user controls include, for example, hard buttons and/or soft keys implemented on a touch screen in conjunction with an ergonomic menu of control options, voice input for user interaction with the device 118, and/or any other suitable means.

Subsystem 408 preferably includes a display monitor (not shown) and speakers (not shown). The display monitor provides guidance as graphical and textual information, and the speaker supplies guidance in the form of pre-recorded or synthesized speech. It will be apparent that rendering subsystem 408 may be implemented partially or entirely external to device 118. In that case, device 118 includes a suitable interface for communicating to subsystem 408. For example, rendering subsystem 408 includes a projection system for a heads-up display to project related information onto the windshield of an automobile (or onto the goggles of a helmet worn by a motorcycle rider). The projection system of an automobile is typically physically integrated with the dashboard. Projection systems for motorcycle riders are integrated in the helmet and are powered by a battery or cord connecting the helmet to the power supply of the motorcycle. The relevant data is then communicated wirelessly (e.g., via a bluetooth interface) or in a wired manner. As another example, the rendering subsystem 408 includes speakers that are components of a built-in sound system of an automobile, or in the case of a motorcycle rider, built into the rider's helmet.

During the trip, the geographic location based on the GPS information is stored in the track storage 410 along with a time stamp. When the device 118 is connected to a user's home PC, for example, in order to receive updates of road maps or updates of software 416 from a service provider via the internet, the data stored in the storage device 410 is sent to the service provider where it is processed unnamed, i.e., not associated with an individual user of the device 118.

GPRS is a known technology. The GPRS modem 404 enables the device 118 to receive data packets via a mobile data service available to a user of a GSM mobile phone. The data rate is approximately 56kbps to 114 kbps. In general, data services provided via GPRS can be point-to-point services (i.e., data communication between two users) and point-to-multipoint (or: multicast, i.e., from one user to many users). With respect to multicast GPRS services, data packets may be broadcast within a particular geographic area. The identifier in the broadcast indicates whether the data packet is intended for all users in the geographic area or for a specific group of users. Within the context of the present invention, this type of service is capable of sending updates regarding traffic information related to users of devices 118 within a particular geographic region.

In the above embodiment, the (re) calculation of the route is performed by the device 118 itself, for which purpose the device 118 houses the processor 414, the database 406 and the software 416. Device 118 receives only real-time traffic updates from server 114 via GPRS modem 404 and then processes the real-time traffic updates to modify the route and generate navigation guidance based on the modified route and its current location according to the onboard GPS receiver.

Fig. 5 is a diagram of a PND 502 in the present invention, the PND 502 being an example of an alternative device to the device 118. Device 502 is implemented as a lightweight client that cooperates with server 114. Device 502 now also includes a wireless transmitter 504 for communicating data to server 114. For example, the transmitter 504 communicates information about the destination of the journey, entered through the user control 412, to the server 114, preferably along with the user's preferences (e.g., provision modality of navigation guidance, such as male or female voice; avoiding motorways; avoiding tolls, etc.). The preferences may be selected by the user for each individual journey, or may have been pre-set to a default mode of operation. Transmitter 504 further communicates data representative of the geographic location of device 502 as determined via GPS receiver 402 to server 114.

Similar to that discussed above, the server 114 (re) calculates the route based on the current location of the device 502, based on real-time traffic information collected from the GSM operator 106 and from the GPS track 108. If a sufficiently large number of vehicles are using a PND configured as lightweight client 502, server 114 has real-time information about the geographic location of these vehicles, which may also be considered at system 100 to generate traffic information 112. Note that also for this reason, the device 502 need not have the trajectory storage 410, as the geographic location of the device 502 is being communicated to the server 114 in real-time.

An advantage of this implementation is that the device 502 may be implemented as a reduced data (lean data) processing device. Another advantage is that server 114 can place navigation guidance for the user of device 502 in a wider variety of situations. This is explained as follows. Server 114 has traffic information and weather information 112 that is relevant not only to the geographic area in which the user of device 502 is currently located, but also to other geographic areas. This means that navigation guidance to the user of the device 502 can be calculated so as to be optimised in respect of the entire area of the current journey from origin to destination. That is, global optimization is possible. Note that, in contrast, device 118 only receives traffic information regarding local traffic conditions and the modification to the route represents a local optimization. For example, consider the following scenario: wherein, in order to guide a user of the device 118 around a local moderate traffic jam in a particular zone, the device 118 provides guidance for a detour that happens to bring the user into an adjacent zone where a severe jam due to a major traffic accident has occurred due to a major chain of crashes. If the user stays on the original route to withstand a moderate degree of inconvenience, he does not encounter severe congestion on the detour. However, such bad luck may be occasional and rare, depending on the density of the roads in the area.

Depending on the bandwidth available at the server 114 and in the wireless communication from the server 114 to the receiver 404, the server 114 may be configured to carry out all of the data processing operations carried out in the device 118 in the previous embodiments. That is, all data processing is delegated to server 114. Next, the processor 414 in the device 502 is now primarily responsible for controlling the rendering subsystem 408 to render the navigation guidance information. The navigation guidance information includes map data received from server 114 on demand to be rendered on a display monitor of subsystem 408, and includes directions received from server 114 to be rendered as speech via speakers in subsystem 408 and/or as graphical icons via a display monitor. In this case, the device 502 itself does not require a database storage device 406 for storing road map data and other geographically relevant data, as all content is being transferred to the device 502.

Note, however, that in order to receive data for detailed navigation guidance from the server 114 (e.g., for rendering a detailed road map on a display monitor), the receiver 404 and the server 114 need to have a sufficiently large bandwidth. GPRS technology may in fact be insufficient to implement the downloading of data from server 114 to device 502. GPRS technology may still be used to upload GPS to server 114. Television technology including dedicated television channels is in principle available for downloading from server 114 to device 502.

Figure 6 is a block diagram of an embodiment 602 of a PND in the present invention, the configuration of which can be considered to be intermediate between that of device 118 and that of device 502. Similar to device 502, device 602 communicates with server 114 using a wireless two-way data communication technique, e.g., GPRS techniques in both receiver 404 and transmitter 504. Similar to device 118, device 602 stores road map data and other related geographic information in database 406. However, the database 406 does not need to store data representing historical average speeds recorded for each individual road segment. The transmitter 504 intermittently (e.g., periodically or selectively depending on, for example, a change in direction of travel) uploads GPS data to the server 114. Thus, the server 114 is always aware of the current geographic location of the device 602. The server 114 downloads the navigation guidance data to the device 602 via the receiver 404. This data is calculated on the basis of the user's destination and the user's current geographic location, and on the basis of historical and real-time traffic information and weather information created in the storage device 112. The creation process has been discussed above, for example, with reference to fig. 2 and 3. As with embodiment 502, one advantage resides in the fact that: the server 112 has available traffic information and weather information for a plurality of geographic areas including the area in which the user is driving or riding. This enables the route to be optimised on a scale larger than that which would be only locally within a single one of the geographical areas. Processor 414, under the control of software 604, processes the navigation guidance data received from server 114 to generate guidance information suitable for the user of device 602. For example, processor 414 generates visual and/or audible instructions on rendering subsystem 408 and combines the guidance information with the relevant road map data retrieved from database 406.

With respect to the user interface aspects of the PND in the present invention (e.g., the device 118, 502 or 602), the following features may contribute to the perceived user-friendliness of the device in operational use.

The first feature relates to the device 118, 502, or 602 configured or programmed to inform the user of a current update to a recent route based on traffic conditions or weather conditions, as described above. The user is notified, for example, by synthesized speech via a speaker of subsystem 408 and/or via a graphical indication on a display monitor in subsystem 408.

The second feature relates to a graphical representation of navigation guidance on a display monitor in a subsystem 408 of the device 118, 502, or 602. For example, a portion of a currently relevant road map is rendered on a display monitor, and a corresponding portion of the route currently in use is projected onto the displayed map portion. The user then forms a picture of the portion of the route and its geographic environment in mind. As described above, at a given moment, the current route is modified due to poor traffic conditions and/or weather conditions in the upcoming leg of the current route. The user then has to readjust the picture in his mind to correspond to the modified route. The device 118, 502 or 602 now graphically indicates both the relevant portion of the previous route and the relevant currently valid portion of the modified route. For example, the previous portion is indicated in red and the currently active portion is indicated in green. Alternatively, the previous portion and the currently valid portion are indicated graphically, e.g., in different dash patterns. The previous portion is indicated by a series of dashes ("- - - -") and the currently valid portion is indicated by a series of addition marks ("+ + + + + + + + + +"). The latter option is preferred if the user is color blind. A configuration menu accessible by the user control device 412 enables the user to select a preferred way of indicating the previous and currently valid portions in operational use of the device 118, 502 or 602.

The third option involves providing information to the user of the device 118, 502 or 602 regarding the reason for the current modification to the route. For example, the data received from server 114 includes an identifier that is processed by processor 414 to select one of a plurality of predefined icons or text to be rendered in subsystem 408, the icons and text representing a reason. For example, if the cause is a severe congestion due to a traffic accident, an icon showing a car turning on its side is selected. As another example, an icon corresponding to a traffic symbol conventionally used to indicate slippery roads may be used to indicate severe weather conditions as a cause of a route. As yet another example, icons may be selected indicating rush hour traffic, drawbridges, and so forth.

A fourth option involves navigational guidance to drivers (e.g., daily commuters) who know that they will encounter the usual non-avoidable congested traffic on their journey. These users of the detour guide 118, 502 or 602 are not required, nor are they required to be informed of a typical blockage. The commuter may then, for example, turn off the device 118, 502, or 602, or ignore the guidance. A more user-friendly option is then to have the boot operate in a mode: where only unusually severe obstruction (i.e., not very common compared to daily severe obstruction) causes a modified route. The server 114 has information about real-time average speed or traffic volume, and the device 118 and/or the server 114 has information about historical average speed or traffic volume. Such a mode of operation may then be selected: where device 118 or server 114 distinguishes between normal congestion and unusual congestion to enable the route to be selectively modified.

FIG. 7 is a flow diagram of one example of a method performed by server 114 to provide navigation guidance to device 502 or 602 as described above. The method is initiated in step 702. In step 704, server 114 receives information about its departure location, its destination, from device 502 or 602. The departure location may be determined by server 114 from GPS data (received from device 502 or device 602) or may be received as text data via GPRS as a result of a user entering or otherwise selecting the name of the destination through user control device 412. In step 706, server 114 optionally calculates a route in view of the user's preferences and traffic information and/or weather information available at storage device 112. In step 708, server 114 transmits data representing the navigation guidance to device 502 or device 602. Data transmission is established via GPRS. Device 502 or 602 submits, e.g., via GPRS, data representing the current geographic location of the device, e.g., as determined via GPS technology (or another technology). For convenience, this data is referred to herein as GPS data. In step 710, server 114 receives GPS data. In step 712, server 114 determines whether the destination has been reached. If the destination has been reached, the process of the method ends in step 714. If the destination has not been reached, server 114 determines a geographic region corresponding to the location of device 502 or 602 from the received GPS data in step 716. In step 718, server 114 determines traffic information and/or weather information related to the portion of the route currently in effect that is still to be covered (i.e., the route between the current geographic location and the destination). Based on this information, server 114 calculates candidate modifications to the currently valid route in step 720 to determine whether the travel time (or distance to be traveled or a weighted sum of these and other quantities) can be optimized. If server 114 determines that no modifications to the currently valid route are required, the process returns to step 708. If server 114 determines that a modification is required, server 114 creates a modified route in step 722. The process returns to step 708 to supply navigational guidance data based on the modified route.

Claims (8)

1. A mobile navigation device (118) configured for providing navigation information to a mobile user on a road network depending on a geographical location of the device and, after being programmed, guiding the mobile user via a route to a predetermined destination, wherein the device comprises:

a storage (406) for storing information about segments of the road network, the information comprising historical data representing respective historical traffic progress on respective ones of the segments;

a wireless receiver (404) for receiving data indicative of current traffic progress on a segment of a particular road in the section;

a data processor (414) coupled to the receiver and operative to:

determining whether the segment is included in a portion of the route to be traveled;

if the road segment is not included, continuing to use the route;

if the road segment is included, using the historical data to determine an alternative route to the destination based on comparing a first expected travel time of the route to a second expected travel time of the alternative route given the current traffic progress; and

upon a result of the comparison, initiating provision of the navigation information regarding the alternative route.

2. The apparatus of claim 1, wherein:

the second expected travel time is calculated by the processor based on scaling the historical traffic progress on another road in the alternative route by an amount representative of the current traffic progress on the particular road.

3. Software (416) for a mobile navigation device (118), the mobile navigation device (118) being configured for providing navigation information to a mobile user on a road network in dependence of a geographical position of the device and upon being programmed to guide the mobile user via a route to a predetermined destination, wherein the device comprises:

a storage (406) for storing information about segments of the road network, the information comprising historical data representing respective historical traffic progress on respective ones of the segments;

a wireless receiver (404) for receiving data indicative of current traffic progress on a segment of a particular road in the section; and

a data processor (414) coupled to the receiver;

and wherein the software includes instructions for controlling the processor to:

determining whether the segment is included in a portion of the route to be traveled;

if the road segment is not included, continuing to use the route;

if the road segment is included, using the historical data to determine an alternative route to the destination based on comparing a first expected travel time of the route to a second expected travel time of the alternative route given the current traffic progress; and

upon a result of the comparison, initiating provision of the navigation information regarding the alternative route.

4. The software of claim 3, further comprising instructions for the processor to:

calculating the second expected travel time based on scaling the historical traffic progress on another road in the alternative route by an amount representative of the current traffic progress on the particular road.

5. A method of providing navigation information to a user of a mobile navigation device (118) in dependence upon a geographical location of the device for guiding the user to a predetermined destination via a route, wherein the method comprises:

accessing a storage device (406) storing information about segments of a road network, the information comprising historical data representing respective historical traffic progress on respective roads in the segments;

receiving, via a wireless receiver (404), data indicative of current traffic progress on a segment of a particular road in the section;

determining whether the segment is included in a portion of the route to be traveled;

if the segment is not included, using the route;

if the road segment is included, using the historical data to determine an alternative route to the destination based on comparing a first expected travel time of the route to a second expected travel time of the alternative route given the current traffic progress; and

upon a result of the comparison, initiating provision of the navigation information regarding the alternative route.

6. The method of claim 5, wherein the second expected travel time is calculated based on scaling the historical traffic progress on another road in the alternative route by an amount representative of the current traffic progress on the particular road.

7. A method of providing navigation information to a user of a mobile navigation device (502; 602) in dependence upon a geographical location of the device for guiding the user to a predetermined destination via a route, wherein the method comprises:

receiving (710) data representative of the geographic location from the device;

determining (716) a section of a road network related to the route;

determining (718) information about the section, the information comprising historical data representing respective historical traffic progress on respective roads in the section;

determining a current traffic progress on a segment of a particular road in the section;

determining whether the segment is included in a portion of the route to be traveled;

if the segment is not included, using the route;

determining (720) an alternative route (722) to the destination using the historical data based on comparing a first expected travel time of the route to a second expected travel time of the alternative route with the destination knowing the current traffic progress, if the segment is included; and

upon a result of the comparison, initiating provision of the navigation information regarding the alternative route.

8. The method of claim 7, wherein the second expected travel time is calculated based on scaling the historical traffic progress on another road in the alternative route by an amount representative of the current traffic progress on the particular road.