Determining travel information The invention relates to a method and to a device for determining (real-time) travel information. Also, a system comprising at least one such device is suggested.

Common methods for real-time travel time measurement in traffic engineering use detection systems, e.g., inductive loop detectors or video cameras. Via suitable algorithms, fixed detectors can provide accurate travel times of the whole traffic flow, i.e. for each vehicle. These methods, however, require a dedicated and expensive infrastructure as numerous detectors are required along each link.

Furthermore, once the detection system is implemented, the links cannot easily be changed.

Another known approach uses floating car data: Floating cars (e.g., specially equipped cars) transmit their real ^¬ time position. Thus, a central service is able to give estimated information about the current travel times along particular streets or routes. This approach is also

limited, because the floating cars can choose their route individually and a huge amount of cars is required to cover all traffic situations of interest. Additionally, the travel time can be inaccurate or belated in particular as the speed of the floating cars may be different from the speed of the traffic.

An advanced solution uses Floating Mobile Data (FMD) .

Communication Service Providers (CSPs) can monitor vehicles running on dedicated roads based on the position of mobile phones in cars. The phones can be considered as anonymous traffic probes. As almost everybody nowadays uses a mobile phone, the CSPs can provide nearly full country-wide coverage with no additional infrastructure required. However, FMD provides traffic information on limited geographic locations: In a cellular network the location area as minimum resolution to follow the idle terminals amounts to a resolution of 10km to 100km. On a cell area level, the typical resolution to follow an active mobile terminal amounts to 0.1km to 10km) .

The problem to be solved is to provide a cost efficient mechanism to determine real-time travel time in particular on dedicated road segments.

This problem is solved according to the features of the independent claims. Further embodiments result from the depending claims.

In order to overcome this problem, a method is provided for determining a travel information comprising:

- receiving information about a cell change, in

particular a cell change event related to at least one mobile subscriber device traversing a plurality of cells, wherein said cells are located along or in the vicinity of a path of a transport network;

- receiving zone information related to cell change events based on mobile subscriber devices moving or having moved along at least a segment of the path;

- receiving speed information related to at least a portion of the path;

- processing the received information about the cell change on the basis of the received zone

information and the received speed information to determine the travel information along at least a portion of the path.

The path is also referred to as link or dedicated link. The path could be a portion of a route. The cell change event may be a mobile network signaling event or it may be based on such event .

The mobile subscriber device may be any mobile phone or device being (at least temporarily) connected to the mobile network. The mobile network may be any mobile communication network, e.g., based on a UMTS, GSM, LTE, WLAN, Bluetooth, etc. specification.

The solution presents in particular a vehicular travel time estimator based on mobile network signaling events. A travel time server can thus provide real-time estimations on dedicated links in, e.g., road traffic networks (e.g., on freeways as well as on urban roads) .

The solution presented herein can be FMD-based. Travel time of a mobile terminal can be estimated using signaling events, e.g., a handover (HO) or a location area update (LA) . Positions can be recorded when mobile HO/LA occur in the cellular network. Although the HO/LA positions can be assumed to be deterministic, variations may exist.

Therefore, HO/LA events may not be exact positions, but rather zones on a given road if measured multiple times on the same road. The solution can be generalized for any event that happens deterministically in a given geographic zone (e.g. RFID events, WLAN events, Bluetooth events, etc . ) .

The approach presented can be based on offline and/or online data. On the one hand, online signaling data of one or more CSPs can be used. On the other hand, an offline database of the HO/LA zones can be used concerning

dedicated links. A HO/LA database can be set up and

maintained to supply reliable travel time estimation. The database can be created based on theoretical models (radio coverage, road network) and/or measurements. The solution presented solves the problem of real-time travel time calculation on dedicated road segments in particular by using radio signaling data. The invention can be applied to any type of radio signaling data (e.g., cellular network events, Bluetooth technology, etc.), which can be obtained, e.g., in real-time. Moreover, the

signaling is preferably suitable to create sequences of signaling events, i.e. fixed points or zones are provided with rather precise timestamps.

The approach provided herein overcomes in particular the following problems:

- Signaling events are assumed to be deterministic.

They, however, might not occur at the same position at all times. Events can occur in a distributed manner throughout a given zone. Certain zones may be several meters long. The uncertainty of the event positions can generate inaccuracy in travel time calculation.

- The temporal sequence of zones may not follow the spatial sequence on the dedicated link.

- The start/end zone of a temporal sequence may

depend on a user's individual behavior: For example, start/end zone of a phone call is not known in advance.

- False/irrelevant signaling events are at least

partially filtered out.

- Signaling events can be correlated with zone

patterns of the dedicated links.

The method can be generalized for any appropriate radio signaling event. The solution may in particular consider two types of cellular signaling events, i.e., HO and LA, which occur during normal telecommunication operations, and do not require any active user action (e.g., call or SMS) . In an embodiment, the information about a cell change comprises at least one cell change event. In another embodiment, the information about the cell change is based on an event that happens deterministically within a geographic zone.

In a further embodiment, the information about the cell change is received in real-time or substantially in real ^¬ time .

In a next embodiment, the cell change event comprises at least one of the following:

- a location update event;

- a handover event,

- a handoff event,

- a soft handover event,

- an RFID event,

- a WLAN event,

- a Bluetooth event.

The event may in particular be based on any technology that allows for a signaling event to occur (in particular in a deterministic way) within a geographic zone.

It is also an embodiment that the information about a cell change is issued for an anonymous subscriber identity. Pursuant to another embodiment, several cell change events are combined to an event zone, wherein a centroid of the event zone is determined based on the several cell change events and such centroid is used as the received

information about the cell change for further processing. Alternatively the centroid can be calculated from radio propagation models. According to an embodiment, the event zone is determined based on IMEI codes and/or types of mobile subscriber devices .

According to another embodiment, information about a cell change is filtered out if it falls outside a predefined range .

In yet another embodiment, information about a cell change is filtered by dynamic filtering means, which are adjusted based on the fluctuation of the actual traffic.

According to a next embodiment, the information about the cell change comprises at least one of the following:

- a time stamp,

- an old cell id,

- a new cell id

Pursuant to yet an embodiment, said travel information is at least one of the following:

- a travel time;

- a travel distance;

- a travel speed.

According to a further embodiment, said zone information is non-real-time information.

As to a subsequent embodiment, said zone information comprises information based on theoretical models, in particular models with regard to the following:

- a radio coverage map and/or

- a road network. According to a next embodiment, said zone information is based on or comprises historical data, which is in

particular provided by at least one database. The database may gather historical data, e.g., from past movements of mobile devices. Such data can be considered when assessing said travel information.

According to yet an embodiment, said zone information comprises at least one of the following:

- measured data or information;

- offline calculated information;

- GPS information;

- geographic information;

- enriched information.

According to a further embodiment, the transport network comprises traffic along a route, in particular a road, a street, a railway and/or a pedestrian zone.

According to a next embodiment, the zone information comprises a plurality of zone sequences.

According to an embodiment, said zone information comprises for each zone information on expansion and localization of the zone in relation to the path.

Said zone sequences are also referred to as patterns. According to another embodiment, said speed information comprises at least one of the following:

- a maximum speed information;

- a minimum speed information;

- a measured speed information;

- a computed or simulated speed information;

- a speed restriction; - a limitation with regard to the speed.

It is a next embodiment that additional information is provided based on said determined travel information.

It could be an embodiment that said additional information comprises at least one of the following:

- an information regarding a position of at least one of said mobile subscriber devices in relation to the path;

- an information on entering or leaving the path by at least one of said mobile subscriber devices;

- an information related to a reliability and/or

quality of said travel information;

- an information of exceeding a travel information threshold related to a portion of the path;

- an information about waypoints along the path,

which provide a measure for a reliability of the travel information.

Pursuant to an embodiment, the additional information is supplied as a map and/or a histogram.

As to another embodiment, a feedback interface allows adjustment of parameters, in particular timers, used for calculating the determined travel information.

According to yet an embodiment, the path is defined or adjusted dynamically.

The problem stated above is also solved by a device for determining a travel information comprising a processing unit that is arranged

- for receiving information about a cell change, in particular a cell change event related to at least one mobile subscriber device traversing a plurality of cells, wherein said cells are located along or in the vicinity of a path of a transport network; for receiving zone information related to cell change events based on mobile subscriber devices moving or having moved along at least a segment of the path;

for receiving speed information related to at least a portion of the path;

for processing the received information about the cell change on the basis of the received zone information and the received speed information to determine the travel information along at least a portion of the path. It is noted that the steps of the method stated herein may be executable on this processing unit as well.

It is further noted that said processing unit can comprise at least one, in particular several means that are arranged to execute the steps of the method described herein. The means may be logically or physically separated; in

particular several logically separate means could be combined in at least one physical unit. Said processing unit may comprise at least one of the following: a processor, a microcontroller, a hard-wired circuit, an ASIC, an FPGA, a logic device.

The solution provided herein further comprises a computer program product directly loadable into a memory of a digital computer, comprising software code portions for performing the steps of the method as described herein.

In addition, the problem stated above is solved by a computer-readable medium, e.g., storage of any kind, having computer-executable instructions adapted to cause a computer system to perform the method as described herein.

Furthermore, the problem stated above is solved by a communication system comprising at least one device as described herein.

Embodiments of the invention are shown and illustrated in the following figures:

Fig.l shows an exemplary FMD system architecture

supplying travel time observations and travel time change observations; Fig.2 shows an exemplary start HO/LA zone, an

intermediate HO/LA zone and an end HO/LA zone on a dedicated road link;

Fig.3 shows a schematic diagram comprising functional

blocks of the Travel Time Server (TTS) ;

Fig.4 shows a diagram depicting a dedicated link with

projected HO zones, wherein each HO zone comprises a centroid;

Fig.5 shows an exemplary diagram visualizing a pattern- based approach;

Fig.6 shows two dedicated links on the same road pointing in opposite directions;

Fig.7 visualizes HO types defined in the PMQ problem;

Fig.8 shows an example of a travel time histogram,

wherein a travel time being in the range between 40 and 70 are considered valid observations; Fig.9 depicts a workflow of an exemplary TTS implementation; Fig.10 shows a block diagram of the calculator start

block, which accepts inputs from the whole TTS coming from the Cellular Service Providers, i.e. the HO events of the mobile network (s); Fig.11 shows a block diagram of the data windows

operations portion of the TTS algorithm;

Fig.12 shows a block diagram of the part observation

quality calculator, which is realized as window operation providing new part observation (PO) and

POQI from the first and last event of the window;

Fig.13 shows a schematic block diagram of the observation calculator algorithm that determines the

Observation (0) concerning the whole dedicated link;

Fig.14 shows a schematic block diagram of the observation filter;

Fig.15 shows a schematic block diagram of the segment

travel time calculator algorithm, which calculates travel times of all combinations of segments within a current PO;

Fig.16 shows a schematic block diagram of the observation quality indicator (OQI) calculator algorithm;

Fig.17 a schematic diagram visualizing a dynamic link

concept . The solution presented herein correlates real-time radio signaling events with zone patterns in order to provide travel time information on selected road links (also referred to as "dedicated links") .

Fig.l shows an exemplary FMD system architecture supplying travel time observations 101 and travel time change

observations 102. Real-time signaling events 105 are correlated with zone patterns 109 and are fed to a travel time server (TTS) 103 and to an incident tracker server (ITS) 104. The events 105 are saved in a historical event database 106. If the event 105 is a white-listed event, it is saved in a whitelisted event database 107.

The historical event database 106 replays events

(historical signaling events) , which are correlated with zone patterns and are fed to the ITS 104.

Data from the whitelisted event database 107 are correlated and fed to a measurement system 108, which - based on client measurements, GPS measurements and network

whitelisted measurements - conveys measured zone patterns to a zone database 109, which in turn provides zone

patterns to the TTS 103 and the ITS 104.

A theoretical model 110 based on, e.g., radio coverage and/or the road network, supplies theoretical zone patterns to said zone database 109.

A request 111 indicates a need for an incident at a link (e.g., selected road or selected road portion), creates a temporary incident zone pattern (duration) and conveys it to the theoretical model 110. It also conveys a track incident information (for a given duration) to the ITS 104. The approach described herein may be encompassed by the TTS 103 and/or the ITS 104. The TTS 103 correlates real-time signaling events with patterns in the zone database 109. Events from the same anonym subscriber are searched in the zone patterns and partial matches can be determined with a given confidence level. The start and end zone of the partial match is used to calculate travel time on a given road link. Real-time signaling event data may arrive from multiple networks in the country, i.e. from several Communication Service

Providers (CSPs) . In this case, a separate TTS and zone database is required for each CSP, wherein the output of each TTS and zone database can be aggregated at a later stage .

Concepts used in the TTS 103: (a) A HO/LA zone (ZN) is a geographic area where a HO or LA takes place on a road. It can be defined by a unique transition of parameters: <old LAC, old cell ID>, <new LAC, new cell ID>, wherein LAC determines the local area code and ID determines the

identification or identifier of the respective cell. The ZN can preferably be a (single) geographic point; in reality, however, the ZN corresponds to a random distribution of points on the road. An attribute of the zone can be a centroid, i.e. a weighted average its points.

(b) A dedicated link (DL) corresponds to two dedicated

points on a road segment. The DL is directed, e.g., from a start dedicated point SDP to an end dedicated point EDP. The start dedicated point (SDP) is the start point of the dedicated link (DL) and the end dedicated point

(EDP) is the end point (DP, also referred to as destination point) of the dedicated link (DL) .

A start HO/LA zone (SZN) is the nearest HO/LA zone to the given SDP. There is preferably only one SZN on a dedicated link. It is noted that the SZN can be outside of the DL if that is the closest ZN to the SDP.

An end HO/LA zone (EZN) is the nearest HO/LA zone to the given EDP. There is only one EZN on a dedicated link. It is noted that the EZN can be outside of the DL, if that is the closest ZN to the EDP.

An intermediate HO/LA zone (IZN) is a zone between the start zone (SZN) and the end zone (EZN) on a dedicated link. Typically, there are multiple IZNs on a

dedicated link.

A part observation (PO) is a calculated travel time on a given segment. Typically, a PO is a mobile terminal traveling through ZNs (e.g., a mobile call on a dedicated link, not necessarily covering the whole DL) .

An observation (O) is an approximation of travel on a given dedicated link using one or more part observation ( s ) .

Fig.2 shows an exemplary start HO/LA zone, an intermediate HO/LA zone and an end HO/LA zone on a dedicated road link. Functional blocks of the TTS

Fig.3 shows a schematic diagram comprising functional blocks of the Travel Time Server (TTS) .

The TTS comprises a calculator 301 (also referred to as travel time calculator) and an aggregator 302 (also

referred to as travel time aggregator) . The calculator 301 accepts input from a HO feeder 303 as a real-time event stream. It accepts cell change (CC) events with timestamps as input and provides as output part observation matched to a particular dedicated link. Said part observation is fed to the aggregator 302. The aggregator 302 accepts part observations as input and provides observation as output, which is conveyed to, e.g., a consumer 304. The aggregator 302 produces as a second output a median determined based on observations within a time window and conveys it to the consumer 304. The

aggregator 302 can aggregate input from multiple

calculators (i.e. multiple CSPs) .

As feedback, the aggregator 302 conveys a median travel time to the calculator 301 in order to calibrate timers for the part observations.

Further, the calculator 301 may convey database queries to a zone pattern database 305 (which may correspond to the zone database 109 shown in Fig.l) .

Anonymity may be an important aspect of the TTS

realization. Signaling events can be anonymized based on a unique ID of the subscriber (e.g. MSISDN, IMEI) . This anonym ID needs to be unique only during a call, or

predefined period, after that the keys can be re-generated. After the travel time is calculated, the observations are not bound to any anonym user ID that leaves the system; they can be individual observation without being coupled to a user ID. The observations can further be aggregated into median travel time values, making it impossible to trace back the event to individual observations.

Calculation of the maximal potential error in estimated travel time

By knowing the timestamps of the start and end HO zone of a given segment, an average travel time can be calculated. At the same time, a potential error can be taken into account as the HO events do not occur exactly at the same point. The measured HO events generate a HO zone; a centroid of the HO events can be calculated as the mean of projected HO event locations, i.e. the center of gravity.

Fig.4 shows a diagram depicting a dedicated link with projected HO zones, wherein each HO zone comprises a centroid .

L is a segment length between two arbitrary chosen HO zones (projected) centroids. and l ₂ represent HO zone lengths. Tf _ree is a current free flow travel time required to pass the whole segment L. Tf _ree can be calculated by using the speed limitation value and the physical law of speed:

L

free

free

Tf _r ^l _ee is the free flow travel time needed to pass the HO zone from the front to the centroid and τfΙr ^ι, e ⁺ e is the free flow travel time to pass the HO zone from the centroid to the end of the HO zone. Thus, the ratio parameters can be defined as follows: As the distribution of HO events within the HO zones is not known, the worst case is considered again for potential error calculation (event location is considered at the ends of the HO zone) . The following travel times can be

determined for the two extreme (worst) cases: max 7. ¹ free ' ¹ free ¹ free

If these boundary cases are considered, proportion e _{max l} and e _max _ ₂ show a measure of the maximal potential errors calculated travel time as follows:

free free 1free ¹ max _2 I ¹ free ^ ¹ free ¹ free ^ ¹ free

max_2 j.i j,i

free free

It is noted that in this asymmetric case the maximal potential errors in the estimated travel time are not generally identical. Therefore, the bigger maximum

potential error can is selected pursuant to

— max! £ _{max ]} _ , ;

Travel Time Calculator An objective of the (travel time) calculator is to

correlate HO/LA zones with patterns. For this purpose, a pattern-based approach can be used. Based on theoretical models or measurements, HO/LA zones are determined for each dedicated link in the traffic network. Nevertheless, only a part of the zones is selected for travel time calculation (e.g., manually or semi-automatically) . The clustered HO/LA zones define a pattern having a fixed number and a sequence of events. The pattern defines a theoretical chain of HO/LA events considering single direction of each dedicated link. Nevertheless, it can be efficiently used for calculation purposes. Thus, ambiguous or overlapping zones can be removed from the set of measured zones.

Fig.5 shows an exemplary diagram visualizing a pattern- based approach. The zones 501 are defined as a pattern "A- B-C-D-E" and the zones 502 are not used.

Different approaches can be applied concerning the HO/LA zone pattern issue. For example, by using IMEI codes, the measured zones can be classified by the mobile phone types. Thus, patterns can be defined for each terminal type. Since different phone types may provide different HO/LA patterns, the advantage of this method is that orthogonal patterns can be correctly identified for different phone types.

The calculator can use a window-based approach: Hence, for each terminal generating a pattern HO/LA event (i.e. event contained by the set of predefined patterns) a window is opened. This window accepts subsequent pattern events of that terminal. The window closes if the user (identified by encrypted user ID) passes the dedicated link or ends the call. It accepts only pattern HO/LA events. Unassociated events (not included by any patterns) are dropped, yet they may have an impact on a pattern matching quality (PMQ) described later. For each new event the calculator may determine whether or not the user yet has an open window. This may be important in case each user has only one window open at a time.

The calculation can be based on pattern HO/LA events of the window. Thus, only such user devices (mobile phones) are considered for calculation purposes, which generate a reliable sequence matching a pattern. Nevertheless, it is noted that the pattern may be a theoretical chain of HO/LA events. Thus, some error in the pattern is to be tolerated. A typical error regards a missing pattern event. Thus, the calculator tolerates a few numbers (K) of missing pattern events. A suitable choice for the parameter K may depend on the dedicated link's attributes (number of HO zones, link length, etc . ) .

Another potential error may occur when the user leaves the dedicated link and continues his route on another dedicated link. In this case, the current window is closed and a new window can be opened. In this case, at least two events belonging to a different pattern may occur. One such

"foreign pattern event" can be tolerated as it, e.g., may occur in opposite direction. Fig.6 shows two dedicated links 601 and 602 on the same road pointing in opposite directions. If a user is travelling on the dedicated link 601 it may happen that a false HO (indicated by the big HO 603) occurs, but belongs to the dedicated link 602.

The system is also able to detect a mobile terminal turning on a road: For example as shown in Fig.6, a terminal may report HO zones in the following order: 604, 605, 606, 603, and 607. In this case, the system is able to output two observations: one for the direction along the link 601 and after that one for the direction along the link 602. Whenever an event is placed into the window, an expiry timer can be set to a maximum timeout value ( t _max ) during which the window is kept alive. If the timeout is reached and/or exceeded, the window may be closed. The timeout value t _max is calculated based on estimated travel time (if a valid estimation thereof is available) and/or free flow travel time of the segments. The calculation of the timeout value t _max is based on travel time estimations and/or free flow travel time of the segments as well as on said

parameter K. The use of travel time estimate is favorable when there is no explicit end of call event in the input signaling stream; otherwise, the end of call can be used for the same purpose.

The calculator is able to filter and tolerate ambiguous HO/LA events which may often occur in particular in urban environments. A typical problem is a so-called ping-pong effect, wherein ping-pong events are short-period cell changes where the first and last cells are the same (A-B- A) . Another problem is the re-entry effect when the user generates a re-entry into the same cell after several subsequent events (e.g. A-B-C-A-D) .

By using appropriate timers and by setting a suitable level of fault tolerance, the calculator is able to detect the leaving of the dedicated link and the turning back effects. The calculator may in particular provide part observations based on the incoming signaling data. Part observation (PO) mean travel time which can be calculated based on the timestamps of the first and last HO/LA events.

Additionally, a so-called part observation quality

indicator (POQI) of the PO can be determined, e.g., based on the following parameters:

- a segment quality indicator (SQI) and

- a pattern matching quality parameter (PMQ) . The SQI is calculated based on a maximum potential error ( ^£ maxr defined above) of the segment travel time:

SQI = l - e _max , 5Q/G[0,1]. PMQ intends to characterize the matching quality of the HOs of the PO. Fig.7 visualizes HO types defined in the PMQ problem. The PMQ is calculated by considering the following definitions :

- (indicated by reference 701) : the number of all HOs generated by the user during the PO.

^{~ n} patternHO '· (indicated by reference 702) : the number of pattern HOs on the dedicated link between the first and last HO generated by the user in PO. It is noted that all pattern HOs or even a part of them are considered depending on the first and last HO of the PO.

^{~ n} a ^S ttemHO (indicated by reference 703) : the number of pattern HOs generated by the user during the PO.

The PMQ is calculated by using the definitions above

user user

, ^L patternHO „ ^,L patternHO

i ideal _n user

PMQ = ⁿ v"" ^e ™Ho OHHO_ _{PMQ E [( ] >} where a _{l r} and β^ are weighting factors ( α ₁ , β ₁ E R ⁺ ) subjected to the constraint α ₁ + β ₁ = 2 .

The PMQ is useful for detecing a terminal leaving a

dedicated link, as that section of the pattern which is not on the dedicated link will result in unmatching zones, thus

nuser

reducing the PMQ through ' ^{ρ nα} "a ₅ l ^£ l _< H"O ^Η0 )·

Finally, the POQI is defined as follows: a ₂ ^■ SQI + β ₂ ^■ PMQ

POQI POQI ( where a ₂ , and β ₂ are weighting factors similarly to the previous case, i.e. ( α ₂ , β ₂ Ε Μ. ⁺ ) subjected to the constraint ^a 2 + /?2 ⁼ 2 · The weighting factors may differ for the

different dedicated links. Their values can be tuned based on historical signaling events. Travel Time Aggregator

The aggregator part of the TTS is able to accept part observations (POs) from different CSPs. In case of longer routes the POs can be used to estimate travel time of the whole dedicated link. Based on the POs and by using an appropriate extrapolation method, the aggregator may determine observations (0) concerning the whole dedicated link.

Additionally, the quality indicator can be recalculated. Thus, POQI is augmented by the extrapolation inaccuracy: An observation quality indicator (OQI) is calculated based on the POQI as follows:

OQI = POQI where TS is a free flow travel time of the PO and TDL is a free flow travel time of the dedicated link.

The aggregator may comprise an observation filter part to find and drop invalid observations among the incoming data. Signaling data not produced by automobiles may be regarded invalid as the main goal is to provide average travel time of cars along certain dedicated links. This means

observations that stem from bicycles, pedestrians or public vehicles (bus, tram, railway) may have to be filtered out. One possibility to filter unwanted observations is to define a range with constant upper and lower limit of the travel time along the DL . All observations can be dropped that fall outside this predefined range. This approach may work fine in case of non-congested traffic. However, in case of traffic slowing-down by any reason, the filter may wrongly also drop observations from cars. Therefore, a dynamic filter may be required which is able to adapt pursuant to a fluctuation of the actual traffic.

As an example to meet this requirement, a travel time histogram based concept is introduced. The histogram is a graphical representation showing a visual impression of the distribution of data. In the current scenario, the

histogram represents the distribution of observations (i.e. travel times) . Fig.8 shows an example of a travel time histogram, wherein a travel time being in the range between 40 and 70 are considered valid observations. Cyclists and pedestrians may cause observations in the range from 100 to 120 and a travel time of 10 to 30 may indicate false observations .

If a sufficient number of observations are available, it is possible to filter out invalid data. First, a range of valid observations is defined which may vary over time. For example, cyclists and pedestrians can have longer travel time compared to the cars. In order to further avoid false observations, data that fall out of the current range (cars may require a travel time amounting to at least 40) can also be dropped. Passengers of public vehicles (bus, tram, railway) can also be filtered by observing a schedule time. If several observations are arriving at the same time which strongly differs from the mean of the valid observations and the current time coincides with the schedule time, it may be possible to distinguish such observations from the wanted observations of the cars.

The histogram may utilize a moving time horizon with a limited range, e.g., about 5 to 15 minutes. Thus, the histogram remains relevant for the current time. In

contrast, if the horizon is too short, lack of sufficient observations could compromise the applicability of the histogram. The suitable choice for the time horizon length depends on special local properties of the dedicated link in question.

In addition, at a particular time, e.g., during night time, the histogram may not be suited. Thus, a minimum number of observations can be defined for the histogram at each time update (update frequency of the histogram may be, e.g., about one minute) . If there is less observation in the histogram than the predefined minimal number, the histogram will not be considered (too little data makes the histogram irrelevant) . The goal of the observation filter is to find and drop invalid observations among the incoming data. Invalid data can be represented by two types of observations:

(a) Invalid observations:

- An observation that is not produced by cars, but instead by users on bicycle, by pedestrians, etc. Observations that are produced by special cars (e.g. ambulance or police cars moving fast, garbage-collector cars that stops frequently) .

False observations based on noisy data, e.g., a HO occurs far away outside of the predefined HO zone, parallel roads with similar zones.

(b) Valid observation:

- Observations that are generated by mobile phones in common cars .

Observations without significant deviation compared to the average observation, i.e. observations that are within a valid range. Some of the features of the histogram based filter can be summarized as follows:

A range of valid observations may be predefined for the time of the day (e.g., morning, midday, rush hour, winter/summer, holiday season, etc.), amounting to, e.g., 40-70s. Determining of such range may utilize historical measurement data as input.

A histogram of travel times can be built by using observations within a given time window (e.g., 5-15 minutes) . Setting up the time window may utilize historical measurement data as input.

Observations out of the valid range are excluded from the measurements that are processed and are thus not considered in the travel time estimation.

It is noted that a number of the samples needs to exceed a certain threshold as a histogram is useless if observations are low or sporadic, which may

typically be the case during night time.

An important task of the aggregator may be its capability to provide a data feedback for the calculator to refine current free flow travel times on the dedicated link by real-time measurements. Typically, timers (e.g., time to wait for a next HO) can be fine-tuned with current travel times observed on the link.

Further advantages and embodiments:

The solution presented in particular provides the following advantages : (1) The method is able to consider the uncertainty of the event location within the signaling zone. The maximum potential error in the travel time is derived based on the free flow travel times of the zones and the segment .

The TTS uses a pattern-based approach for calculation, where clustered signaling zones can define a pattern having a fixed number and sequence of the events.

(3) The TTS is able to filter out ambiguous or unwanted signaling events (e.g. re-entry or ping-pong effect) and to allow exceptions when correlating the pattern with the real-time signaling data in order to

accommodate to the semi-deterministic signaling patterns of the terminals. Thus, a certain error can be allowed or accepted, e.g., missing pattern events or false sequence of events. (4) The TTS can provide reliable quality parameters (SQI and PMQ) for each PO and an overall OQI as well. The quality indicators serve as parameters to assess the excellence of the TTS estimations. (5) The TTS is able to detect the leaving of the dedicated link and the turning back phenomena.

(6) The TTS involves a feedback capability to refine the timers of the calculator block, i.e. the travel time calculation process can be improved by real-time free flow travel time measurements.

(7) The TTS may realize a histogram based on filtering for travel times. Exemplary Embodiments:

Fig.9 depicts a workflow of an exemplary TTS

implementation. Hereinafter, the blocks depicted in Fig.9 are described in further detail.

(1) CALCULATOR START BLOCK

Fig.10 shows a block diagram of the calculator start block. The block accepts inputs from the whole TTS coming from the Cellular Service Providers, i.e. the HO events of the mobile network (s) .

In a step 1001, the program examines if the subscriber (identified by encrypted user ID) already has an opened window (stream) . This is a suitable examination as an opened (i.e. running) window may belong to one subscriber only. Moreover, a subscriber cannot have more than one opened window at the same time. If no window is opened for the subscriber at a current time, a new window can be started depending on further conditions. If the subscriber already has an opened window, the current HO event can be placed in the window depending on further conditions. According to a step 1002 or a step 1003, the program examines if any of the HO zones (stored in the database) is associated with the current HO event. The database may contain only those HO zones which are selected for travel time estimation of the dedicated links. If no window is opened for the subscriber, the unassociated (i.e.

irrelevant) HO events are dropped. However, in case of an existing window, the unassociated HO events are forwarded to block number (2) Data Window Operations for optional further processing (e.g. detect link leaving). (2) DATA WINDOW OPERATIONS

Fig.11 shows a block diagram of the data windows operations portion of the TTS algorithm. The block accepts all HO events and Window IDs arriving from the Calculator Start Block.

An exemplary ideal case of the work flow passes blocks that are marked with " (X) " .

In this ideal case no problem occurs concerning the

arriving HO zones, i.e. the HOs follow the pattern

accurately without any problem.

In a step 1101, a first investigation is to examine if the current HO is first in the window.

Step 1102: If the current HO is the first event in the window, the first step is to get the relevant pattern (from data base) for the HO. Thus, the HO event is placed into the window with the knowledge of the pattern.

Step 1103: If the current HO is not the first in the window, an investigation is required to decide whether the HO is contained by the pattern.

Step 1104: It may happen that the current HO event does not fit in the pattern for a single time (this observation is based on test measurements) . However, all other previous and next events may match the pattern. This can occur typically when the opposite direction of the current link is also a dedicated link (with HO zones stored in the data base) . Therefore, HOs from the opposite direction may be obtained. In the current solution, one false HO event

(false means that HO is not contained by the pattern assigned for the window) may be allowed if the next HO follows again the pattern. To realize this option, a fault flag can be used in the algorithm, which is set if a false HO occurs (at the same time the first false HO is stored) . Thus, if a correct HO is measured for the second time, this fault flag can be reset.

Step 1105: If the fault flag option is already defined, the window is closed and forwarded to the PO calculator without the previous and current HOs, i.e. the false HOs . Step 1106: The previous false HO is fed back to the

calculator start block as input where a new window may be started .

Step 1107: The current false HO is fed back to the

calculator start block as input where a new window may be started .

Step 1108: The block investigates if the current HO event is identical to the last HO in the window. In case of a newly opened window, the question is meaningless and the answer can always be "No".

Step 1109: For the case of identity (i.e. re-entry into the same HO zone) a critical interval (CI) can be defined. If the successive HO occurred after a time less than the CI, this may be based on a re-entry. Thus, only the current HO is considered, i.e. the last HO can be overwritten in the window. If the successive HO occurred later than the CI, the current window can be stopped and forwarded without the current HO to the PO calculator. At the same time, the current HO event is placed into a new window. The CI may be set to, e.g., 30s .

Step 1110: It is beneficial to investigate the order of the current HO compared to the last HO in the window. This is examined if the current HO is direct or at most the Kth event in the pattern. Practically, the parameter K is used to define the maximal (admissible) number of missing HO zones compared to an ideal case, i.e. the HO zones of the pattern. The suitable choice for the parameter K depends on the dedicated link's attributes (number of HO zones, link length, etc.) . In an exemplary test case, K was set to 11.

Step 1111: Whenever a HO event is placed into the window, the expiry timer is reset to a maximum timeout value (t _max ) during which the window is kept alive. If the timeout is exceeded, the window is closed. The value t _max is calculated based on an estimated travel time (if valid estimation is available) and/or a free flow travel time of the segments. Step 1112: The calculation of t _max is based on travel time estimations and/or free flow travel time of the segments. t _max can be calculated considering the next K segments of the pattern. Thus, the sum of the travel times of the K segments can be investigated. If valid and not too old (e.g. not exceeding a maximum age of 15min) , an estimation (calculated, e.g., by the segment travel time calculator in the aggregator) is available for the current segment and the estimation will be applied. If no valid travel time estimation exists for the current segment, only the free flow travel time can be used (calculated from speed

limitation of the segment) . Finally, the algorithm forwards the travel times of the K segments.

Step 1113: When all travel times (calculated from

estimations and/or free flow travel times) arrive, the maximum timeout value t _max can be calculated as the sum of the weighted travel times:

tmax ∑ ^αί where i = l,...,K, and a± is a weighting factor. It is assumed that the value of a± can be smaller in case of valid travel time estimation. For example, the value of a± can be set to 3 , i = 1, ... , K .

(3) PART OBSERVATION CALCULATOR

Fig.12 shows a block diagram of the part observation quality calculator, which is realized as window operation providing new part observation (PO) and POQI from the first and last event of the window.

Step 1201: A PO mean travel time can be calculated based on the timestamps of the first and last events.

Step 1202: The SQI is calculated from the maximal potential error ( e _max ) of the segment travel time as follows:

Step 1203: The algorithm calculates the POQI of the PO based on the SQI and the pattern matching quality parameter (PMQ) . POQI represents a percentile value, i.e. POQI E [0, 1] . The reference implementation used identical weighting factors, i.e. a = a ₂ = β = β ₂ = 1 ·

(4) OBSERVATION CALCULATOR Fig.13 shows a schematic block diagram of the observation calculator algorithm that determines the Observation (0) concerning the whole dedicated link.

The algorithm realizes an extrapolation based on the travel time of the current part observation arriving from the part observation calculator. The observation is calculated based on the free flow travel times of the DL and the segment of the current PO. This operation may preferably be or

comprise an approximation. (5) OBSERVATION FILTER

Fig.14 shows a schematic block diagram of the observation filter. This is an optional portion of the implementation. (6) SEGMENT TRAVEL TIME CALCULATOR

Fig.15 shows a schematic block diagram of the segment travel time calculator algorithm. It calculates travel times of all combinations of segments within a current PO.

It provides feedback to the calculator block (for the data window operation) . Valid segment travel times can be used to continuously refine the timeout value of the expiry timer .

(7) OQI CALCULATOR

Fig.16 shows a schematic block diagram of the observation quality indicator (OQI) calculator algorithm. The

calculation of OQI is required due to the extrapolation from the PO to the 0.

The Incident Tracker Server (ITS) The ITS can provide historical and real-time travel time information on dynamically created links around an incident point. The ITS processes events similarly to the TTS, but instead of working on static links, it provides information on demand, on a given incident point (ICP) of a link. The ITS calculates a dedicated link by searching for available zones starting from the ICP in both directions. Several search patterns can be implemented (e.g., select N zones to the left and N zones to the right of the ICP on a given directed link; filter zones with a high daily count; weight zones by the distance of the zone to the ICP, etc.) .

Based on this dynamic link and zone information, the zone database can be updated, and the calculation may commence. First, with historical signaling data is fed to the system in order to produce n hours of history, after that real ^¬ time signaling data is processed to provide real-time observations. For example, handovers of each anonymous call may match at least one zone before the ICP and one after the ICP.

Fig.17 shows a schematic diagram visualizing a dynamic link concept. An incident point (ICP) 1701 is located on a directed link 1702 with several zones.

On the link 1702 there are several zones from two

operators, zones of an operator A are indicated by circles a to f and zones of an operator B are indicated by

triangles 1 to 6.

In this case a mixed dynamic link is created by searching for a minimum of two zones for both operators in two directions. The dynamic link 1703 is created from operator A zone d to operator B zone 1. It is noted that a mobile terminal producing a pattern [1,2,3] creates a dynamic observation as it crosses the ICP 1701, but neither [1,2], nor [3,4,5] would match such pattern. Similarly, a pattern [b,c,e] would match, but a pattern [a,b,c] would not match. List of abbreviations

CC Cell Change

CI Critical Interval

CSP Communication Service Provider

DL Dedicated Link

EDP End Dedicated Point

EZN End HO/LA Zone

FMD Floating Mobile Data

GPS Global Positioning System

HO Handover

HOICP Handover Incident Point

ICP Incident Point

IMEI International Mobile Equipment Identity

ITS Incident Tracker Server

IZN Intermediate HO/LA Zone

LA Location Area Update

0 Observation

OQI Observation Quality Indicator

PMQ Pattern Matching Quality

PO Part Observation

POQI Part Observation Quality Indicator

SDP Start Dedicated Point

SQI Segment Quality Indicator

SZN Start HO/LA Zone

TDL Free flow travel time of DL

TS Free flow travel time of PO

TTS Travel Time Server

ZN HO/LA Zone

ZNITS Incident Tracker Server HO/LA Zone