WO2018220637A1

WO2018220637A1 - Server node, mobile client device and methods for location reporting

Info

Publication number: WO2018220637A1
Application number: PCT/IN2017/050214
Authority: WO
Inventors: Sudipta DUTTA; Arindam Banerjee; Arup Kumar Roy
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2017-05-31
Filing date: 2017-05-31
Publication date: 2018-12-06

Abstract

A mobile client device (202), a server node (200) and methods therein, for reporting location of the mobile client device (202) and for supporting mobility tracking of the mobile client device (202). The server node (200) estimates (2:1, 2:2) a route travelled by the mobile client device (202) and determines (2:2) an uncertainty vector based on the estimated route. The uncertainty vector comprises a required reporting frequency and a maximum permissible travelled distance since a foregoing location report. The uncertainty vector is sent to the mobile client device (202) as an instruction for location reporting. The mobile client device (202) then applies (2:4) the uncertainty vector for location reporting such that when any of said reporting frequency and maximum permissible travelled distance is reached (2:5), the mobile client device (202) obtains its current location and sends (2:6) a location report accordingly to the server node (200).

Description

SERVER NODE, MOBILE CLIENT DEVICE AND METHODS FOR LOCATION

REPORTING

Technical field

The present disclosure relates generally to a mobile client device, a server node and methods therein, for reporting location of the mobile client device and for supporting mobility tracking of the mobile client device.

Background

Mobility tracking of vehicles and other moving or travelling entities is becoming increasingly important and desirable, e.g. for public transport vehicles such as taxis and busses, as well as for fleets of trucks and other vehicles for transport of goods. In the above examples it is thus often appropriate or even required to keep track of where a number of moving vehicles or other entities are located and which routes they travel.

Location information of a vehicle or the like is generally obtained when a wireless device in the vehicle determines its current location, e.g. by means of a Global Positioning System (GPS) function, and sends a location report with the determined location over a wireless network to a server node where the location information can potentially be processed and used, or at least accessed. In conventional proceedings, the location reports are sent regularly at more or less fixed intervals to the server node. For example, location information from a wireless device in a travelling vehicle may be used for predicting at what time the vehicle is likely to arrive at a certain destination, and/or for scheduling the vehicle for future operations and routes, and so forth.

In this description, the term "mobile client device" is used to represent any wireless device that is capable of determining its current location and of sending a location report with the determined location to a server node. It may be assumed that the mobile client device can be installed or carried on a moving vehicle or other item that is of interest to track. It can therefore be said that the mobile client device described herein is associated with and carried by such a moving vehicle or other item.

Further, the term "server node" denotes in this description a communication entity which the mobile client device can communicate with over a wireless network, particularly for delivering location reports. It is further assumed that the server node can send messages to the mobile client device in order to control operation of the mobile client device in terms of location reporting. For example, the server node may be owned or at least accessed by a party that is potentially interested in acquiring location information about the mobile client device. The location reports discussed herein may alternatively be called location updates, and the term "location" may alternatively be called "position" as a synonym term. The server node discussed herein may alternatively be called a location server, or a mobility tracking server.

It was mentioned above that location reports are typically sent at regular intervals over a wireless network and if there is a large number of mobile client devices that send such reports frequently, the load on the wireless network and other communication links used may be substantial due to such regular location reporting. This is naturally a drawback, particularly when the available resources such as radio resources are limited in the network. On the other hand, the location reports should be sent with at least a certain frequency sufficient to ensure that the device can be tracked with adequate precision at any time, once needed.

Fig. 1 illustrates a communication scenario where a mobile client device in a vehicle 100 sends location reports "LR" at regular time intervals tl, t2, t3 . . . to a server node 102 over a wireless network 104. This means that each location report LR is sent after the same fixed time duration since the foregoing report. A couple of example base stations 104 A belonging to the network 104 are also shown and the mobile client device is connected to them in the shown succession when the vehicle 100 travels as indicated by the dotted arrows.

It is shown that a location report LR1 is sent from the device in the vehicle 100 at the time tl over one of the base stations 104A. After a preset and typically fixed time interval, a next location report LR2 is sent from the vehicle 100 at the time t2 over another one of the base stations 104A, and a further location report LR3 is sent from the vehicle 100 at the next time t3 over a third one of the base stations 104A. It is also shown that the next location report LR4 is sent from the vehicle 100 at the time t4, when the vehicle 100 has stopped at or before t3 which means that LR3 = LR4. The following location report(s) may also be equal, as long as the vehicle remains at the same location. The frequency or interval at which a mobile client device reports its location data to the server node is henceforth termed as reporting frequency. Another problem with the above conventional procedure for location reporting is that a huge number of location reports are habitually sent from mobile client devices, resulting in great load on the wireless network used. For example, many of the sent location reports may not be needed to achieve adequate tracking of the mobile client devices, and such reports are therefore sent more or less in vain, thus adding load on the network to no avail. Yet another problem is that frequent sending of location reports consumes energy on the transmitting side so that a battery in the device may be drained in short time. Yet another problem is that frequent reception of location reports causes load on the server node as well which needs to receive and process the incoming flood of location reports, often to no avail if the information is not really important or needed.

Summary

It is an object of embodiments described herein to address at least some of the problems and issues outlined above. It is possible to achieve this object and others by using a mobile client device, a server node and methods therein, as defined in the attached independent claims.

According to one aspect, a method is performed by a mobile client device for reporting location of the mobile client device to a server node. In this method, the mobile client device receives from the server node an uncertainty vector comprising a required reporting frequency and a maximum permissible travelled distance since a foregoing location report was sent to the server node. A current location of the mobile client device is then obtained when at least one of the reporting frequency and the maximum permissible travelled distance in the uncertainty vector is reached, and the mobile client device sends a location report with the obtained current location to the server node.

According to another aspect, a mobile client device is arranged to report location of the mobile client device to a server node. The mobile client device is configured to receive from the server node an uncertainty vector comprising a required reporting frequency and a maximum permissible travelled distance since a foregoing location report was sent to the server node. The mobile client device is also configured to obtain a current location of the mobile client device when at least one of the reporting frequency and the maximum permissible travelled distance in the uncertainty vector is reached, and to send a location report with the obtained current location to the server node. According to yet another aspect, a method is performed by a server node for supporting mobility tracking of a mobile client device. In this method, the server node receives one or more location reports from the mobile client device, and estimates a route travelled by the mobile client device based on the received location report(s). The server node then determines an uncertainty vector based on the estimated route, the uncertainty vector comprising a reporting frequency and a maximum permissible travelled distance since a foregoing location report was sent from the mobile client device. The server node finally sends the uncertainty vector to the mobile client device as an instruction to apply the uncertainty vector for location reporting. According to yet another aspect, a server node is arranged to support mobility tracking of a mobile client device. The server node is configured to receive one or more location reports from the mobile client device, and to estimate a route travelled by the mobile client device based on the received location report(s). The server node is also configured to determine an uncertainty vector based on the estimated route, the uncertainty vector comprising a reporting frequency and a maximum permissible travelled distance since a foregoing location report was sent from the mobile client device. The server node is further configured to send the uncertainty vector to the mobile client device as an instruction to apply the uncertainty vector for location reporting.

By estimating the mobile client device's travelled route and instructing the mobile client device to adapt its location reporting according to the uncertainty vector, it can be avoided that unnecessary location reports are sent frequently when the route is well-known anyway and the mobile client device's location can be foreseen with less frequent location reports from the mobile client device. Thereby, advantages that can be achieved include reduced load on the wireless network used and reduced energy consumption in the mobile client device.

The above mobile client device, server node and methods therein may be configured and implemented according to different optional embodiments to accomplish further features and benefits, to be described below.

A computer program is also provided which comprises instructions which, when executed on at least one processor, cause the at least one processor to carry out either of the methods described above. A carrier containing the above computer program is further provided, wherein the carrier is one of an electronic signal, an optical signal, a radio signal, or a computer readable storage medium.

Brief description of drawings

The solution will now be described in more detail by means of examples and possible embodiments and with reference to the accompanying drawings, in which:

Fig. 1 is a communication scenario illustrating a regular procedure for location reporting from mobile client device in a vehicle to a server node, according to the prior art.

Fig. 2 is a signaling diagram illustrating an example of a procedure when the solution is used, according to some example embodiments. Fig. 3 is a flow chart illustrating a procedure in a mobile client device, according to further example embodiments.

Fig. 4 is a flow chart illustrating a procedure in a server node, according to further example embodiments.

Fig. 5 is a flow chart illustrating an example of how a mobile client device may operate in more detail, according to further example embodiments.

Fig. 6 is a flow chart illustrating an example of how a server node may operate in more detail, according to further example embodiments.

Fig. 7 is a block diagram illustrating how a mobile client device and a server node may be structured, according to further example embodiments. Fig. 8 illustrates an example of how a server node may be implemented in practice, according to further example embodiments.

Fig. 9 is a block diagram illustrating an example of how a mobile client device may be realized in more detail, according to further example embodiments.

Fig. 10 is a block diagram illustrating an example of how a server node may be realized in more detail, according to further example embodiments. Detailed description

As indicated in the Summary section, a solution is provided that can reduce the number of location reports sent to a server node from a mobile client device, or "device" for short, which in turn will reduce the load on the wireless network used and also reduce energy consumption in the device. This can be accomplished by making the reporting frequency adaptive and dependent on how well a route can be predicted or estimated for the mobile client device, e.g. based on previous travelling behavior or the like. For example, if the server node can estimate the route taken by the mobile client device with good accuracy and certainty, the mobile client device can be allowed to send location reports more seldom than if the estimated route is more indefinite.

For example, the estimated route may be well-known and travelled by the device frequently at regular intervals, but on the other hand it could also be a route that the device has seldom or never travelled before. The location reporting is controlled by sending an "uncertainty vector" from the server node to the mobile client device, containing two parameters: a required reporting frequency and a maximum permissible distance travelled by the device since a foregoing location report was sent. The term "reporting frequency" has been defined above. The uncertainty vector thus reflects how certain the estimated route is and how often the device needs to send location reports in order to get adequate knowledge of its whereabouts. It is envisaged that the location reports will in most cases, using the solution described herein, be sent more seldom than if the conventional procedure with reports at fixed intervals is used.

This can be done basically as follows. The server node is able to estimate the route based on one or more initial regular location reports from the mobile client device. The server node then determines the uncertainty vector based on the estimated route and sends the uncertainty vector to the mobile client device as an instruction for location reporting. The mobile client device then applies the uncertainty vector such that when any of the two parameters therein is reached, the mobile client device obtains its current location and sends a location report accordingly to the server node. In some embodiments, if the device detects that it does not follow the route as expected, or is travelling with unforeseen speed, the mobile client device may send an "early" location report well before any of the parameters in the uncertainty vector has been reached. An example of how the solution may be employed will now be described with reference to the signalling diagram in Fig. 2 involving a server node 200 and a mobile client device 202 which communicate over a wireless network 204. For example, the mobile client device 202 may operate in a travelling vehicle that is desirable to track, which is possible to do by means of the following procedure. The terms "mobile client device" and "server node" used herein have been defined and explained above. The server node 200 may be part of or otherwise connected to the wireless network 204.

A first action 2:1 illustrates that, having started to travel, the mobile client device 202 sends one or more regular location reports to the server node 200. In this context, the term "regular" indicates that the location reports are not sent according to any uncertainty vector but according to a predefined scheme, i.e. reporting frequency, assuming that so far the route has not been detected or confirmed by the server node 200 and the mobile client device 202 has thus not yet received an uncertainty vector.

In another action 2:2, the server node 200 estimates the route based on the regular location report(s) from the device 202, which may include a number of reports needed to identify a road or street, and determines the above-described uncertainty vector based on the estimated route. In some cases, it may be sufficient to receive just one regular location report from the device 202 that confirms that it has started to travel on a route usually travelled at this time of day or this day of the week, and so forth. Some examples of how a travelled route can be estimated with varying certainty will be described below with reference to Fig. 6. Action 2:2 may be executed "gradually" when receiving more and more location reports as of action 2: 1, so that actions 2:1 and 2:2 overlap.

In a next action 2:3, the server node 200 sends the uncertainty vector to the mobile client device 202 as an instruction to apply the uncertainty vector for location reporting. Accordingly, the mobile client device 202 applies the uncertainty vector in an action 2:4, which thus comprises two parameters: 1) a required reporting frequency i.e. the duration between reports, and 2) a maximum permissible travelled distance since a foregoing location report was sent from the mobile client device 202. It is assumed that the mobile client device 202 starts a timer each time having sent a location report to the server node 200, and also starts measuring its travelled distance from the last reported location, so that the mobile client device 202 keeps track of the two parameters so as to know when it is time to send the next location report. When at least one of the two parameters in the uncertainty vector is reached, as detected in an action 2:5, the mobile client device 202 obtains its current location and accordingly sends a location report to the server node 200 in an action 2:6. Thereby, the server node 200 is able to calculate the mobile client device's 202 travelled distance and location at any time after receiving the report, basically by extrapolating the reported location along the estimated route based on the time that has passed since the report was received and the device's 202 assumed travelling speed.

In this example, the server node 200 then updates the uncertainty vector based on the received location report in an action 2:7, by adjusting the reporting frequency and/or the maximum permissible travelled distance. For example, the location report may indicate that the certainty of the device's 202 location has changed such as when the device 202 approaches a road junction or the like, or when the device 202 has unexpectedly changed its speed e.g. due to heavy traffic or an obstacle, which implies that the certainty is reduced. The certainty may also have been increased e.g. when the location report confirms that the device is travelling as expected on a road with no junctions ahead.

The server node 200 sends the new updated uncertainty vector to the mobile client device 202 in an action 2:8 and the mobile client device 202 applies the new uncertainty vector in a further action 2:9. Hence, the uncertainty vector can be adapted to the circumstances in a dynamic manner and be kept up-to-date in the course of travelling the route. Next time any of the two parameters in the new uncertainty vector is reached, as detected in an action 2:10, the mobile client device 202 obtains its current location and accordingly sends its next location report to the server node 200 in an action 2:11, and so forth.

An example will now be described with reference to the flow chart in Fig. 3, of how the solution may be employed in terms of actions performed by a mobile client device such as the above-described mobile client device 202. Fig. 3 is described below with further reference to Fig. 2. Some optional example embodiments that could be used in this procedure will also be described below. This procedure may be employed when the mobile client device 202 is connected to a wireless network 204 which may be of any type and any suitable protocols and standards for communication may be employed in this network 204. The mobile client device 202 in this procedure is arranged to report location of the mobile client device 202 to a server node such as the above-described server node 200 which is able to communicate with the device 202 over the wireless network 204. A first action 300 illustrates that the mobile client device 202 receives from the server node 200 an uncertainty vector comprising a required reporting frequency and a maximum permissible travelled distance since a foregoing location report was sent from the mobile client device 202 to the server node 200. This action corresponds to action 2:3 in Fig. 2.

In a next action 302, the mobile client device 202 obtains a current location of the mobile client device 202 when at least one of the reporting frequency and the maximum permissible travelled distance in the uncertainty vector is reached, whichever comes first, which corresponds to action 2:5 in Fig. 2. Another action 304 illustrates that the mobile client device 202 then sends a location report with the obtained current location to the server node 200, which corresponds to action 2:6 in Fig. 2. Thereby, the server node 200 can determine the mobile client device's 202 expected location at some point before receiving the next location report, by extrapolating the latest reported location as described above for Fig. 2.

Some further embodiments and examples of how the above procedure in Fig. 3 may be realized, will now be outlined. In one example embodiment, the current location of the mobile client device 202 may be monitored over time and the device 202 may send a next location report to the server node 200 immediately if the monitored current location indicates that a travelled distance since a foregoing location report exceeds a threshold relative to a predicted distance derived from the location of said foregoing location report. Sending the new location report "immediately" implies that it is sent before any of the two parameters in the uncertainty vector is reached. An example of how this embodiment could be implemented will be described below with reference to the flow chart in Fig. 5.

In another example embodiment, each location report may comprise a state vector including values of current location and speed of the mobile client device 202. The state vector thus indicates the current state of the mobile client device 202 in terms of location and travelling speed. From this information, the server node 200 is able to calculate the mobile client device's 202 travelled distance and location at a time after receiving the report, basically by extrapolation of the reported location along the estimated route based on the time length since the report and the travelling speed. For example, if the reported speed is 50 kilometers per hour, the device' s 202 location at 10 minutes after sending the report is expected to be 1/6 x 50 = 8,3 kilometers away from the last reported location on the estimated route. The location can sometimes be approximated in this way even if the speed is not included in the location report, by knowledge of prevailing speed regulations on the travelled route and assuming that the mobile client device 202 more or less follows the speed regulations which may be 50 kilometers per hour, as an example.

In another example embodiment, the state vector may further include a value of current acceleration of the mobile client device 202. This could enable the server node 200 to derive speed variations over time and calculate the mobile client device's 202 travelled distance and location even more accurately.

In another example embodiment, the values in the above-described state vector may indicate a change of said values since the foregoing location report, instead of indicating the full absolute values which require a greater number of bits than just indicating the change. Thereby, the size of the communicated information may be minimized or at least reduced as compared to reporting the full absolute values.

In further example embodiments, the mobile client device 202 may send a next location report to the server node 200 immediately when detecting an exception condition which may comprise at least one of the following: A) The device's 202 travelled route is blocked or jammed, which means that the mobile client device 202 cannot continue on the route as expected, for example the speed must be reduced considerably or a detour must be taken.

B) The mobile client device 202 has stopped altogether, for whatever reason, which means that it will be delayed on the route depending on how long the stop takes before starting to move again.

C) The mobile client device 202 has changed to a different route, for whatever reason, which means that it will not follow the estimated route as expected and its whereabouts are more or less unknown. In this alternative, it may be possible for the server node 200 to make an estimation of the new route and determine a new uncertainty vector accordingly, basically as described for action 2:2 in Fig. 2 above, based on the latest location report and possibly one or more further regular location reports from the mobile client device 202.

The above-mentioned term "exception condition" thus indicates that something unexpected has happened so that the mobile client device 202 deviates from its expected movements and its true location can no longer be extrapolated by the server node 200 based on the foregoing report, predicted route and speed. In the latter embodiments, the mobile client device 202 thus sends the next location report "earlier", i.e. before the reporting frequency or the maximum permissible travelled distance in the uncertainty vector is actually reached, so that the true location will be known by the server node 200 as soon as the exception condition is detected by the mobile client device 202. When receiving such an early location report, the server node 200 may adjust the uncertainty vector by increasing the reporting frequency and/or reducing the maximum allowed travelled distance, and send the new updated uncertainty vector to the mobile client device 202.

In another example embodiment, the mobile client device 202 may thus receive an updated uncertainty vector from the server node 200, which is illustrated as an optional action 306, after at least one location report has been sent according to the forgoing uncertainty vector. This action corresponds to action 2:8 in Fig. 2. In this case, the mobile client device 202 applies the updated uncertainty vector for location reporting to the server node 200. Another optional action 308 illustrates that the mobile client device 202 sends a location report to the server node 200 according to the new uncertainty vector, which corresponds to action 2: 11 in Fig. 2. This way, the uncertainty vector can be kept up-to-date in the course of travelling the route.

For example, the server node 200 may need more frequent location reports if the mobile client device 202 approaches a road junction or the like where it is uncertain which direction it will take, out of two or more alternative directions. On the other hand, it may be sufficient with less frequent location reports e.g. when the mobile client device 202 travels as expected on a road with few junctions and no other potential uncertainties.

In another example embodiment, the current location may be obtained from a Global Positioning System, GPS, function which is employed at the mobile client device 202. In another example embodiment, the mobile client device 202 may operate in a travelling vehicle, as also mentioned above, although the solution and its embodiments are not limited thereto.

An example will now be described, with reference to the flow chart in Fig. 4, of how the solution may be employed in terms of actions performed by a server node such as the server node 200 in Fig. 2. Fig. 4 is described below likewise with further reference to Fig. 2. Some optional example embodiments that could be used in this procedure will also be described below.

The server node 200 in this procedure is arranged to support mobility tracking of a mobile client device 202. A first action 400 illustrates that the server node 200 receives one or more location reports from the mobile client device 202, which corresponds to action 2: 1 in Fig. 2. The location report(s) in this action may be sent from the device 202 according to a regular scheme or according to a previously provided uncertainty vector.

In a next action 402, the server node 200 estimates a route travelled by the mobile client device 202 based on the received location report(s). As mentioned above, it may be sufficient to receive a single location report which confirms that the device 202 has started to travel the same route as before at this time of day, week or month, meaning that this route is now highly predictable for this mobile client device 202 to travel. In this case, the certainty of the device's 202 location is deemed high and it only needs to report location relatively seldom, as controlled by one or both of the two parameters in the uncertainty vector.

Some examples of how the travelled route may be estimated will now be described in more detail. In some example embodiments, the route may be estimated further based on a street network map and travelling history of the mobile client device 202, the latter indicating how the device 202 has travelled in the past relative to the street network map. In another example embodiment, said travelling history may in that case have been determined based on historical location data previously reported by the mobile client device 202. Another example embodiment may be that the travelling history have been determined by applying machine learning on the historical location data. If machine learning is not applied, the mobile client device's 202 travelling history may have been determined by identifying, based on the historical location data, different routes previously travelled by the device 202 and determining how often and when those routes have been travelled, e.g. depending on time of day, week or month.

In a further action 404, the server node 200 determines an uncertainty vector based on the estimated route, the uncertainty vector comprising a reporting frequency and a maximum permissible travelled distance since a foregoing location report was sent from the mobile client device 202. Actions 402 and 404 correspond to action 2:2 in Fig. 2. The server node 200 then sends the uncertainty vector to the mobile client device 202, in a following action 406, as an instruction to apply the uncertainty vector for location reporting, which corresponds to action 2:3 in Fig. 2. Some further embodiments and examples of how the above procedure in Fig. 4 may be realized, will now be outlined. It was mentioned above that the server node 200 may adjust and update the uncertainty vector based on one or more received location reports. In one example embodiment, the uncertainty vector may be updated based on at least one subsequent location report received from the mobile client device 202 after the uncertainty vector was sent, and the updated uncertainty vector may then be sent to the mobile client device 202 as an instruction to apply the updated uncertainty vector for location reporting. In another example embodiment, the uncertainty vector may in that case be updated by increasing the reporting frequency and/or reducing the maximum permissible travelled distance, when the subsequent location report indicates that the mobile client device 202 approaches a road junction or that the mobile client device 202 has departed from the estimated route. In either case, the uncertainty is deemed to be increased, although in other cases it may be reduced instead, as explained above.

The server node may be implemented in a logic entity which may be a single node or distributed over two or more nodes. In another example embodiment, the server node may be implemented as a master server node and a set of local server nodes receiving and handling location reports from mobile client devices in respective geographic areas. This embodiment will be further described below with reference to Fig. 8.

An example will now be described with reference to the flow chart in Fig. 5, of how the procedure of Fig. 3 may be performed in more detail. Fig. 5 thus illustrates some useful actions that may be performed by the above-described mobile client device 202.

Reference will also be made to Fig. 2. In a first action 500, the mobile client device 202 receives from the server node 200 an uncertainty vector that comprises the two above-described parameters, namely the required reporting frequency and the maximum permissible travelled distance. The mobile client device 202 accordingly applies the uncertainty vector and starts to monitor its current location in an action 502.

It was mentioned above that the device 202 may send an "early" location report immediately if the monitored current location indicates that a travelled distance since a foregoing location report exceeds a threshold relative to a predicted distance derived from the location of said foregoing location report. This can be implemented such that the mobile client device 202 checks, in an action 504, whether the monitored location indicates a deviation from its expected movements that exceeds a configurable predefined threshold, so that the device's 202 location can no longer be extrapolated by the server node 200 with sufficient accuracy based on the foregoing report. If so, the mobile client device 202 skips actions 506, 508 and proceeds immediately to perform action 510 of obtaining the current location and action 512 of sending a location report accordingly to the server node 200. The above-mentioned configurable predefined threshold may be configured depending on various circumstances and requirements in the wireless network, requirements for the location accuracy, the type of mobile client device used, and so forth.

It was further mentioned above that the mobile client device 202 may send a location report to the server node 200 immediately when detecting an exception condition. Some examples A-C of exception conditions were described above. Hence, if the deviation from its expected movements does not exceed the threshold in action 504, the mobile client device 202 further checks, in another action 506, whether such an exception condition can be detected or not. If so, the mobile client device 202 can skip action 508 and immediately performs actions 510 and 512 as described above.

If neither of the terms in actions 504 and 506 is true, the mobile client device 202 can move to action 508 and check whether any of the two parameters in the uncertainty vector has been reached yet. If so, actions 510 and 512 are performed as required by the uncertainty vector, and if not, the mobile client device 202 returns to action 502 and repeats the following actions in the above-described manner. After sending a location report to the server node 200 in action 512, the mobile client device 202 may receive a new updated uncertainty vector from the server node 200, as indicated by the dashed arrow back to action 500.

An example will now be described with reference to the flow chart in Fig. 6, of how the procedure of Fig. 4 may be performed in more detail. Fig. 6 thus illustrates some useful actions that may be performed by the above-described server node 200. Reference will again also be made to Fig. 2.

A first action 600 illustrates that the server node 200 retrieves a travelling history of the mobile client device 202 which may be comprised of saved location reports that the mobile client device 202 has sent in the past. In a further action 602, the server node 200 receives one or more location reports from the mobile client device 202, which corresponds to action 400. As mentioned above, the location report(s) may be sent from the device 202 according to a regular scheme or according to a previously provided uncertainty vector.

In a next action 604, the server node 200 evaluates which route is currently travelled by the mobile client device 202, based on the received location report(s) and on the travelling history retrieved in action 600. The server node 200 then checks in a next action 606, whether the mobile client device 202 is travelling on a regular route, meaning that the device 202 has travelled that route regularly in the past. This conclusion may be indicated by the travelling history and the current location report(s) from the device 202. If so, the route can easily be estimated in an action 616 and an uncertainty vector can be determined accordingly in another action 618. The server node 200 will then send the determined uncertainty vector to the mobile client device 202 in a final action 620.

On the other hand, if the server node 200 finds that the travelled route is not regular in action 606, it proceeds to check in another action 608, whether the route is known at all. If so, the server node 200 can identify one or more streets, based on a street network map, which cover(s) the locations reported in the received location report(s), as shown by another action 610. In this case, the travelled route is deemed to be non-regular but known since it can be identified on the street network map. The server node 200 is then able to perform the above-described actions 616-620.

However, if the server node 200 finds that the travelled route is not even known in action 608, such as when it cannot even be identified on the street network map. In this case, the travelled route is deemed to be unknown since it cannot be identified on the street network map. Special measures need therefore be taken before the server node 200 is able to identify the route travelled by the device 202, as follows. The following actions 612 and 614 are schematic and will typically involve some manual operation. In an action 612, further location reports made by other mobile client devices are obtained, which locations cannot be found on any streets according to the current street map which is thus apparently incorrect and not up to date. This may be done in order to gather more information about where the other mobile client devices have been able to travel, which could be useful for updating the current street map. In another action 614, the obtained location reports are then compared with the street network map and the street network map is updated to include streets that cover the reported locations. The server node 200 will then be able to perform the above- described actions 616-620 for further received location reports.

The block diagram in Fig. 7 illustrates a detailed but non-limiting example of how a server node 700 and a mobile client device 702, respectively, may be structured to bring about the above-described solution and embodiments thereof. In this figure, the server node 700 and the mobile client device 702 may be configured to operate according to any of the examples and embodiments of employing the solution as described herein, where appropriate. Each of the server node 700 and the mobile client device 702 is shown to comprise a processor "P", a memory "M" and a communication circuit "C" with suitable equipment for transmitting and receiving messages and information in the manner described herein.

The communication circuit C in each of the server node 700 and the mobile client device 702 thus comprises equipment configured for communication with each other using a suitable protocol for the communication depending on the implementation. The solution is however not limited to any specific types of messages or protocols.

The mobile client device 702 is, e.g. by means of units, modules or the like, configured or arranged to perform at least some of the actions of the flow charts in Figs 3 and 5 and as follows. Further, the server node 700 is, e.g. by means of units, modules or the like, configured or arranged to perform at least some of the actions of the flow charts in Figs 4 and 6 and as follows. The mobile client device 702 is arranged to report location of the mobile client device 702 to a server node 700. The mobile client device 702 is configured to receive from the server node 700 an uncertainty vector comprising a required reporting frequency and a maximum permissible travelled distance since a foregoing location report was sent to the server node 700. This operation may be performed by a receiving module 702A in the mobile client device 702 as also illustrated in actions 300 and 500.

The mobile client device 702 is further configured to obtain a current location of the mobile client device 702 when at least one of the reporting frequency and the maximum permissible travelled distance in the uncertainty vector is reached. This operation may be performed by a location module 702B in the mobile client device 702, as also illustrated in actions 302 and 510.

The mobile client device 702 is further configured to send a location report with the current location to the server node 700. This operation may be performed by a reporting module 702C in the mobile client device 702, as also illustrated in actions 304 and 512. . The server node 700 is arranged to support mobility tracking of a mobile client device 702. The server node 700 is configured to receive one or more location reports from the mobile client device 702. This operation may be performed by a receiving module 700A in the server node 700, as also illustrated in action 300.

The server node 700 is also configured to estimate a route travelled by the mobile client device 702 based on the received location report(s). This operation may be performed by an estimating module 700B in the server node 700, as also illustrated in action 302.

The server node 700 is further configured to determine an uncertainty vector based on the estimated route, the uncertainty vector comprising a reporting frequency and a maximum permissible travelled distance since a foregoing location report was sent from the mobile client device 702. This operation may be performed by a determining module 700C in the server node 700 as also illustrated in action 404.

The server node 700 is further configured to send the uncertainty vector to the mobile client device 702 as an instruction to apply the uncertainty vector for location reporting . This operation may be performed by a sending module 700D in the server node 700 as also illustrated in action 304. The sending module 700C could alternatively be named an instruction module or a control module.

It should be noted that Fig. 7 illustrates various functional modules in the server node 700 and the mobile client device 702, respectively, and the skilled person is able to implement these functional modules in practice using suitable software and hardware equipment. Thus, the solution is generally not limited to the shown structures of the server node 700 and the mobile client device 702, and the functional modules therein may be configured to operate according to any of the features, examples and embodiments described in this disclosure, where appropriate. The functional modules 700A-D and 702A-C described above may be implemented in the server node 700 and the mobile client device 702, respectively, by means of program modules of a respective computer program comprising code means which, when run by the processor P causes the server node 700 and the mobile client device 702 to perform the above-described actions and procedures. Each processor P may comprise a single Central Processing Unit (CPU), or could comprise two or more processing units. For example, each processor P may include a general purpose microprocessor, an instruction set processor and/or related chips sets and/or a special purpose microprocessor such as an Application Specific Integrated Circuit (ASIC). Each processor P may also comprise a storage for caching purposes. Each computer program may be carried by a computer program product in each of the server node 700 and the mobile client device 702 in the form of a memory M having a computer readable medium and being connected to the processor P. The computer program product or memory M in each of the server node 700 and the mobile client device 702 thus comprises a computer readable medium on which the computer program is stored e.g. in the form of computer program modules or the like. For example, the memory M in each node may be a flash memory, a Random-Access Memory (RAM), a Read-Only Memory (ROM) or an Electrically Erasable Programmable ROM (EEPROM), and the program modules could in alternative embodiments be distributed on different computer program products in the form of memories within the respective server node 700 and mobile client device 702. The solution described herein may be implemented in each of the server node 700 and the mobile client device 702 by a computer program comprising instructions which, when executed on at least one processor, cause the at least one processor to carry out the actions according to any of the above embodiments and examples, where appropriate. The solution may also be implemented at each of the server node 700 and the mobile client device 702 in a carrier containing the above computer program, wherein the carrier is one of an electronic signal, optical signal, radio signal, or computer readable storage medium.

It was mentioned above that the server node 700 may be implemented as a master server node and a set of local server nodes, to implement and accomplish the above- described features and embodiments. Fig. 8 illustrates that a master server node 800 is connected to a plurality of local server nodes including the shown local server node A denoted 800A and local server node B denoted 800B. The local server node 800A receives and handles location reports from those mobile client devices that are located in a geographic area 802A, also denoted "Zone A", while the local server node 800B receives and handles location reports from those mobile client devices that are located in a geographic area 802B, also denoted "Zone B".

An example of how the above-described mobile client device may be realized in practice, will now be described in more detail with reference to the block diagram in Fig. 9. The mobile client device 900 in this example comprises the following functional modules or units: location traffic manager is a subsystem of the mobile client device 900 that receives data from different sensors such as: GPS sensor, optional odometer etc. If the client side apparatus is a mobile phone device, the distance calculation can be done in a GPS based Map instead of using an odometer. The location traffic manager handles a data transmission policy, checks for exceptional conditions and communicates with the server node 1000 via a client dispatcher and a client receiver, see below. An example of how a data transmission policy may be employed is illustrated by the following schematic processing code:

1. procedure DataTransmission_Policy()

2. START Procedure

3. if GPS == LOCK then

4. location <— GPS location

5. Send location 6. lastLockTime = now()

7. Uncertainty = 0

8. CASE 1: Speed value is available

9. s = getSpeedQ

10. GPS = OFF

11. CASE 2: Speed value is not available

12. GPS = Keep it ON

13. else

14. Uncertainty = U(t)

15. CASE 1: Speed value is available

16. if (GPS == OFF and (U(t)+ (t_tf * s ) > U_max or {counters tf)> t) then

17. GPS = ON

18. Send exception message

19. end if

20. CASE 2: Speed value is not available

21. d = getDistanceTravelledSinceLastLockTime()

22. if(d > U_max or (counter + ty) > t) then

23. Send exception message

24. end if

25. end if

26. END procedure

Further subsystems of the location traffic manager are as follows:

Differential generator generates a differential change in location values. It stores the last value in its local storage, compares the current value with the last value and provides the differential (+/-) between the current value and the last value, which may also be referred to as the "delta" for short, as output. The differential generator is also capable to send absolute location data to the server node 1000, if requested. The term "delta" thus refers to the difference between the current value and the last value, i.e. the change of the value since the previous location report. Data transmission policy handler: The reporting frequency is adaptively set so that the client dispatcher below sends location data to the server node accordingly. The data transmission policy handler also checks for uncertainty measurement sent by the server node 1000 in form of uncertainty vector, and may adjust the reporting frequency adaptively according to the latest received uncertainty vector. A transmission trigger condition can occur due to adaptive time overflow or distance overshoot as against the uncertainty vector set by the server node 1000. In that condition, it asks the uncertainty reactor below to send the location report to the server node 1000. The uncertainty reactor is also asked to send the location report to the server node in case the above-described exception condition is notified to this subsystem by sensors installed in the mobile client device. Some examples of the exception condition and how it may be noticed have been explained above in the description of Fig. 3 and also in the description of Fig. 5, see action 506.

Uncertainty reactor sends the location data to the server node as per the trigger of predefined uncertainty received from data transmission policy handler.

In addition to the above-described location traffic manager, the mobile client device 900 in this example further comprises:

Local memory configured to save limited amounts of data temporarily. In case of link failure or data loss during transmission, data of recent past can be sent again to the server node 1000.

Client dispatcher: This unit sends location reports to the server node 1000.

Client receiver: This unit receives messages such as uncertainty vectors from the server node 1000.

An example of how the above-described server node may be realized in practice will now be described in more detail with reference to the block diagram in Fig. 10. Below, the route travelled by the mobile client device 900 will sometimes be referred to as a "trajectory". Further, the mobile client device 900 will sometimes be referred to as the "client" for short, while the term "device" could replace the term "client" in the description below. The server node 1000 comprises mainly two functional components, namely a street network matrix generator and a location aggregator system as follows.

Street network matrix (SNM) generator converts GPS based map data into a street graph and stores that graph or map in the form of matrices in a database. The street network graph may be generated by sourcing GPS based map data from a federative project such as "OpenStreetMap". The street graph stored in the database comprises a street matrix, a connectivity matrix, a type matrix and a dimension matrix, as shown in the figure. The definition of these matrices and how they can be generated will be described further below. Location aggregator system operates in real time to calculate the uncertainty vector in terms of adaptive reporting frequency and a maximum permissible travelled distance , i.e. the two parameters therein. This system also handles exception conditions. A learning system and a pattern generator operate with existing state-of-the-art machine learning regression procedures. The uncertainty vector with maximum permissible travelled distance and adaptive reporting frequency is determined considering the computation delay and transmission delay. The following sub systems may be included in the location aggregator system: Node registration system: For inclusion of a new device, the device first needs to be registered with a unique identity (Id), e.g. an equipment number. The node registration system generates this unique identity, stores in server's local storage and acknowledges back to the device 900 with this unique Id. Each device stores its own unique Id. Next time onwards, every time device is identified at the server node by this Id. The node registration system may also be called a client registration system.

Learning system: This component holds the machine learning functionality (such as: clustering and classification) to learn a hypothesis of the device's mobility from historical data.

Pattern generator: From the learned hypothesis of the device's mobility, this component extracts device specific trajectory pattern, ranks trajectory in terms of frequency of travel and stores them in a local storage. State vector estimator: This component performs trajectory estimation of a device when the device travels in regular paths or even if it deviates from the regular paths. The state vector estimator leverages the matrices generated by SNM generator for calculating the estimations. Predictive determination of the above -described state vector may be based on Double Exponential Smoothing (DES). As mentioned above, the state vector may comprise three parameters: location, velocity and acceleration (optional) of the mobile client device. In this solution, a modified DES scheme may be used to produce a smoothed time series customized for this system. The details of trajectory estimation will be described below. Uncertainty estimator: This subsystem determines the uncertainty vector in terms of next permissible distance to travel from current location of device and adaptive reporting frequency, considering the computation delay and data transmission delay between server side and device side apparatuses. The uncertainty vector may be determined based on duty cycling strategies to be described below. The uncertainty in the strategy may be estimated by leveraging the matrices generated by the SNM generator, a learned travel pattern, the current state vector of the device and speed constraints of the streets.

Exception handler: This subsystem handles the exception when it is generated by device ignoring the adaptive reporting frequency. Exception handler accepts the exception, processes it, updates the revised location data in database and rectifies the future estimation accordingly.

Common backend database is used for both the location aggregator system and street network matrix generator system.

Server dispatcher: The server node sends data to the device through the dispatcher.

Server receiver: The server node receives message from the device through receiver component.

The above-described client-server communication may be performed according to current standard, open Machine-to-Machine (M2M) communication protocol (for example: Message Queue Telemetry Transport MQTT, Hypertext Transfer Protocol HTTP, etc.) for power constrained devices and low -bandwidth, high-latency networks. A possible message packet format that may be used in this solution is described below.

The payload content of the message request may be devised in JSON format that holds serialized location information.

The payload content of the message response payload Contents may be devised in JSON format that holds probable distance of the client with adaptive reporting frequency. Request format:

When a vehicle carrying the mobile client device starts moving for the first time, it registers itself in the server node and sends the complete latitude and longitude values initially and thereafter the delta values are sent to the server node as shown below. Delta values may be formed into IEEE 754 interchange format and sent to the server node. In this format, the numerical delta value is presented as (-l)^s x c x b^q' where s = a sign (zero or one), c = coefficient, q = exponent. However, some potential characteristics of this system include:

Mobile client devices do not require sending the value of s explicitly, for every data transmission to the server node.

Mobile client devices do not require sending the value of q at all. q is always considered as -8.

- The value of s would be stored in local variables at both client and server sides. It would be sent during initiation. And it would not be sent again until value of s is changed. In GPS location data, this value is expected not to be changed too frequently. Some examples of location reporting are presented below.

Case 1: Initiation - latitude is 23.12345678 and longitude is 88.12345673

{

"location": {

"deltaLat": "{s: 0, c: 2312345678} ", // s and c are sent

"deltaLong": "{ s: 0, c: 8812345673 J ",

"timestamp ": "data "

}

1

Case 2: Vehicle has moved by <11 km. New latitude is 23.12345679 and longitude is

88.12345676

f

"location": {

"deltaLat": "{s: , c: 1} ", //only c is sent

"deltaLong ": "f s: , c: 3} ",

"timestamp ": "data "

}

1

Case 3: Delta value is negative in both latitude and longitude. New latitude is 23.12345677 and longitude is 88.12345673

{

"location": { "deltaLat": "(s: 1, c: 2 J ", //s and c are sent

"deltaLong": "f s: 1, c: 3} ",

"timestamp ": "data "

}

1

As the payload components are being sent adaptively based on differential (+/-) values, its size has been reduced significantly. Response format: Response is sent from server node to client in below J SON format. {

"Uncertainty _Vector" : { "distance": "data"

"adaptiveFreq": "data"

}

1 It will now be described how a street network can be represented and handled when employing the solution described herein.

A city street network can be represented as a graph G (V, E) with V vertices set and E edges set, where E £ V X V. This graph G is developed from the map data of a city with corresponding location data and traffic information. A weight function w; E→ !_¾ assigns a non-negative weight to every edge to represent the length. The length of a curved street having multiple edges is calculated as summation of all the straight edges. A path from source node ni to destination node n_d is actually a sequence of edges (ni, n₂), (n₃, n₄), ... , (nd-i, nd) represented as a sequence of vertices ... ¾_., }. A single edge e_i E E represents a single street if the street is a straight line and vertex v_t £ Vis the endpoint of a street. So, a straight street has two endpoints. If the street consists of one or more curves, it can be represented as multiple edges with their respective vertices. An edge consists of a set of points with location data ( latitude-longitude) such that e_i = f {φί,ΑΪ}, ( ?2„A2).« (φη,Άη}}. Each vertex has its own location data,

;η_έ = (φί,λι). All this information could be stored in a backend database.

The mobile client device may perform the following basic steps to reach a destination: 1. Determine the destination.

2. Select a nearest vertex to reach to the destination.

3. Select an average speed and acceleration for that particular street segment.

4. Pause at the end point whenever required.

5. Once an end point reaches, select the next vertex and initiate the next movement (V, A,) towards destination.

6. Repeat 2 to 5 until the destination is reached.

This procedure addresses a tradeoff between network traffic and localization performance in a mobile sensor network application. It will be used to explore duty cycling strategies for maintaining position uncertainty within specified bounds. Location based mobile client device tracking applications can tolerate a fixed uncertainty in the client's positions. Position uncertainties vary based on street end points.

Associated matrices

The street network matrix generator shown in Fig. 10 stores some associated matrices in a database, such as:

Street matrix 5 = |¾_r¾, -- .■· ¾] (here, ^T means transpose of a matrix) with all n number of streets present in the city,

Connectivity matrix C for connectivity having dimension of n x n that holds the information of connections among streets (or lanes),

- Type matrix T = [t_lf t_2> t }' having dimension of m x 1, holds the types of streets, Dimension matrix D— d_s> d^¹ for the dimensions of all vertices. If d > 2, then that can be a road crossing with traffic signal.

It was described above that the travelled route may be either of three alternatives referred to as the following types 1-3: Type 1) the route is regular and has been travelled several times before by the mobile client device. Type 2) the route is known and can be identified in a street network map but non-regular as it has not been travelled regularly by the mobile client device. Type 3) the route is unknown since it cannot be identified in the street network map. Examples of how these three types may be handled will now be described. Type 1) mobile client device travels a regular route.

First the mobile client device starts sending its GPS location to the server node using some M2M communication protocol at regular intervals (referred to as "probe frequency") τ. Once the server node understands that the mobile client device is traveling in a regular and known trajectory, it starts making the process adaptive.

The last state vector x is stored. Uncertainty U_max is estimated and time to travel U_max amount of distance (t_u) with this speed and acceleration is calculated.

Server node responds back to the mobile client device about the estimated adaptive reporting frequency (f_u = l/t_u) where ^ £ 2^÷ and expected distance travelled before sending next location data. Server node estimates the future values using a new modified Double Exponential Smoothing technique. Since t_u > during this t_u amount of time, the backend system estimates and updates the mobile client device' s location in database as per interval τ whereas the mobile client device does not send actual location by this time. After t_u time period, the mobile client device again sends a location report (e.g. delta values in coordinates) to the server node. If the difference between actual location and estimated location comes under acceptable error limit e_a, then it' s fine. e_a is actually radius of a circle around the exact location of the mobile client device at time t_u. If the mobile client device' s actual location falls outside of this circle, the frequency of sending location data increases until the estimation is corrected in subsequent readings.

As the mobile client device keeps monitoring its location by getting current GPS coordinates, the mobile client device calculates t_u and U(t). If both or either one exceeds the amounts received from the server node in a response message, the mobile client device sends an exception message with its current location to the server node. Example flow for Type 1:

Stepl: Convert existing street map data to street network graph G(V,E) .

Step2: Learning phase for SNM Generation. Develop the all necessary matrices related to Street network graphs- Street Matrix, Connectivity Matrix, Type Matrix, Dimension Matrix.

Step3: Learning phase for trajectories of mobile client devices.

The mobile client devices tracked by this system would be registered first so that each mobile client device gets a unique client ID.

The travel patterns of the mobile client devices are learnt from data of a particular span of time, referred to as training data. Studies have found that despite the diversity of a driver's travel history, drivers often follow simple predictable patterns. The training data would be used to extract the patterns from each mobile client device's travel history. Such patterns may include frequently followed trajectories, e.g. a set of streets, average speed of the mobile client device in certain route segments, average acceleration of the mobile client device in certain route segments, etc.

Type 2) mobile client device travels a non-regular but known route.

A street network map is available for that particular route but the mobile client device does not follow that route regularly.

The procedure is the same as for Type 1 but the θι and θ₂ weights of Double Exponential Smoothing (DES) are changed.

The classification of road and other street network graph related data are retrieved from historical data. The mobile client device's uncertainty vector is calculated accordingly.

Type 3) mobile client device travels an unknown route.

If a new street is opened in the city, the street network graph may not have its information at first. The graph is updated in two ways - i) periodical updates from the street map data and ii) updates when a mobile client device sends GPS location data for a complete new trajectory. The first scenario is quite straight forward. For the second scenario:

When the server node detects that the mobile client device is travelling in an unknown trajectory, the server node asks the mobile client device to send location data at regular frequency (probe frequency) until it detects that the mobile client device again enters into a known street.

The location data can be treated as outliers and alarm event generated. The alarm can trigger manual intervention from City Civic body or to Road Transport Authority Body.

It was mentioned above that the uncertainty vector may be determined based on Duty Cycling Strategies, which will now be described in more detail.

The reporting frequency of location reporting should be set so that the mobile client device sends location reports adaptively. When the system is confident and uncertainty is low, the frequency of location reporting from the mobile client device, can be decreased. Here, a so-called bounded area of the mobile client device is measured and it ensures that the next GPS measurement occurs within a defined radius of the previous measurement. The estimated uncertainty grows linearly with time. When it approaches the maximum allowable uncertainty limit, the mobile client device's GPS location data is sent in a location report again to the server node.

Application specific hyper parameter assumption:

A) Acceptable error limit in location of mobile client devices

B) Acceptable uncertainty limit - expressed in the units of the measured quantity (length of street): U_max

Attributes considered for modelling the mobile client device's mobility:

(1) The distribution of past speed data of the mobile client devices,

(2) The current state vector (as discussed later), and

(3) The maximum average speed for the street.

When a GPS receiver is switched on in a mobile client device, it needs to gather data from at least three or four GPS satellites before it can report its position. Time To First Fix (TTFF) is a measure of the time required for a GPS receiver to acquire satellite signals and navigation data, and calculate a position solution. GPS then suggests the position measurements with its Dilution of Precision (DOP). Computing uncertainty at server side apparatus:

There are multiple factors considered for computing the uncertainty vector at the server node:

- uncertainty is pertinent at junction i.e. uncertainty measure increases as dimension of vertex V (junction) increases. If dimension = 2 for a junction, then that junction has least uncertainty for location estimation.

- uncertainty is more in case device travels in a trajectory which is available in street network graph but not regularly or not at all followed by that device. It will be computed through trajectory estimation as described below.

- uncertainty is more in corner case - if a new street in the city map is discovered, sudden unexpected congestion in the road etc. which are not aligned with patterns extracted from historical data in learning phase.

Context specific parameters at server node:

- Vertex specific factor = Ω. Uncertainty increases at a factor of Ω while dimension increases at junction.

- Unexpected event specific factor = T . Uncertainty increases at a factor of η while unexpected events occur.

- Step factor of adaptive reporting frequency - it measures how the adaptive reporting frequency is incremented/ decremented from its last value (for example: 5% of last value).

Server node calculates the uncertainty vector i.e. maximum permissible distance to be travelled before sending next location data by device and adaptive reporting frequency. The adaptive reporting frequency is calculated from the last existing frequency by step factor. From the learned travel pattern, current state vector of the vehicle, current mean speed in that edge (street), maximum permissible speed of that edge, server then calculates a new adaptive reporting frequency, Ω and η so that the next maximum permissible distance must be less than U_max. Uncertainty Model: Here the uncertainty model is that at any point of time, the location of the mobile client device is within a certain distance from its last reported position. GPS location is received at time ti and after that the uncertainty of location of mobile client device increases linearly with time t. If average speed is s and acceleration is a:

.-'1 \

U(t) - s X (i - t_t) l - X a X (i - t_t } ^:

An uncertainty region of a mobile client device at time t, denoted by U(t), is a bounded region such that the mobile client device can be found inside this region. An uncertainty probability density function of a mobile client device, denoted by F(x, y, t) is a probability density function of the mobile client device' s location (x, y) at time t, that has a value of 0 outside U(t). F(x, y, t) is a probability distribution function having the following property:

I F{x_sy, t) dx dy = 1

Dynamic uncertainty at server side: U_max is dependent on dimension d of vertex. As the uncertainty increases, the server side apparatus estimates higher adaptive reporting frequency. When a mobile client device is about to reach a junction point (vertex), there remains uncertainty of taking one of the streets from d number of options. To confirm the road taken by the mobile client device after crossing the junction, server estimates the distance in uncertainty vector as (L + AL) - where L is the distance of the mobile client device' s current location to junction and AL is a small part added to differentiate the road. With higher adaptive reporting frequency after junction point, server can detect the next road taken after junction even though streets are of same type and length with similar traffic condition.

Handling uncertainty at mobile client device side apparatus: The Umax can dynamically vary as a function of the device' s position and is the distance of the mobile client device from the vertex i.e. street' s end point. If the mobile client device is L meters away from the next end point, it may simply be required that the next time the GPS makes a measurement, it will not have crossed the vertex. If the mobile client device s speed is s meter/second then next transmission of location can be triggered after (L/s - t_tf) seconds, where t_tf is TTFF.

U < U_max needs to be determined. The mobile client device may be equipped with GPS sensor. It may also have optional speed data (OBD).

Trajectory estimation:

This system takes into consideration the location of mobile client devices e.g. in vehicles. It estimates the trajectory of the mobile client devices applied to the integration of GPS measurements even with curves where the estimated future position of the vehicles will not be a straight path.

In this system, a state vector consisting of three parameters is considered including location, velocity and acceleration (optional) of the mobile client devices. mtitu.de

longitude

velocity

Modified Double Exponential Smoothing:

The server node needs a predictive tracking mechanism which would be accurate, fast, robust and simple to implement. Any system introducing latency into rendering predicted location is unwanted. A fast prediction procedure is therefore to be preferred since it is desirable to minimize any additional latency. Exponential smoothing is a technique for smoothing time series data but here Double Exponential Smoothing (DES) may be used which is customized for predicting the mobile client device's location.

The raw data sequence of observations is represented by {x_t}, beginning at time t = 0. The term { s_t} is used to represent the smoothed value for time t, and the term {b_t} is a smoothed trend value at time t. a e [0,1) is the data smoothing factor and β e [0,1) is the trend smoothing factor. A grid search of these two parameters space with values ranging from 0.1 to 0.9, incrementing by 0.1 can find the best values. The best values have the smallest Mean Absolute Error (MA Error). S_s = mx_e - - (i— «)( S_s__t -f- b_s__t) b_t = β(5, - S_t→) + (1 - }b_t→

Forecast value of F after time period τ;

F_s÷. = (S_t - rb_s} -

_f5_s3 It was mentioned above that θι and θ₂ are weights of DES. The Forecast value can be predicted by aggregating a weighted sum of smoothed value and historical value. Historical influence is calculated by taking the minimum between average of F in that street segment and street type. F can be speed or acceleration, however if the mobile client device travels in a new trajectory, θι is considered as 1 and θ₂ as 0 since road type matrix does not hold historical acceleration and historical speed values are not stored for new trajectory.

Data Transmission using Open M2M communication protocol:

MQTT is a light weight, open source publish/subscribe messaging transport protocol designed for power constrained devices and low -bandwidth, high-latency networks. MQTT with bandwidth efficiency, data agnostic nature, and continuous session awareness, helps in minimizing the resource requirements for Internet of Things (IoT) devices. MQTT may provide reliability and assurance of delivery to a larger extent.

MQTT is ideal for large networks of small devices that need to be monitored or controlled from a back-end server on the Internet.

Here MQTT could be used for M2M communication of location data transmission. The delta change in location data would be embedded in MQTT protocol to be transferred from mobile client device to backend server.

While the solution has been described with reference to specific exemplifying embodiments, the description is generally only intended to illustrate the inventive concept and should not be taken as limiting the scope of the solution. For example, the terms "mobile client device", "server node", "location report", "uncertainty vector", "reporting frequency", "state vector" and "exception condition" have been used throughout this disclosure, although any other corresponding entities, functions, and/or parameters could also be used having the features and characteristics described here. The solution is defined by the appended claims.

Claims

1. A method performed by a mobile client device (202) for reporting location of the mobile client device (202) to a server node (200), the method comprising:

- receiving (300, 2:3) from the server node (200) an uncertainty vector comprising a required reporting frequency and a maximum permissible travelled distance since a foregoing location report was sent to the server node (200),

- obtaining (302) a current location of the mobile client device (202) when at least one of the reporting frequency and the maximum permissible travelled distance in the uncertainty vector is reached (2:5), and - sending (304, 2:6) a location report with the current location to the server node (200).

2. A method according to claim 1, wherein the current location of the mobile client device (202) is monitored (502) over time and a next location report is sent to the server node (200) immediately (506) if the monitored current location indicates that a travelled distance since a foregoing location report that was sent to the server node exceeds a threshold relative to a predicted distance derived from the location of said foregoing location report.

3. A method according to claim 1 or 2, wherein each location report comprises a state vector including values of current location and speed of the mobile client device (202).

4. A method according to claim 3, wherein the state vector further includes a value of current acceleration of the mobile client device (202).

5. A method according to claim 3 or 4, wherein the values in the state vector indicate a change of said values since the foregoing location report was sent to the server node.

6. A method according to any of claims 1-5, wherein a next location report is sent to the server node (200) immediately (510) when detecting an exception condition comprising at least one of: a travelled route is blocked or jammed, the mobile client device (202) has stopped, and the mobile client device (202) has changed to a different route.

7. A method according to any of claims 1-6, wherein an updated uncertainty vector is received (306, 2:8) from the server node (200) after at least one location report has been sent to the server node according to the forgoing uncertainty vector, and the updated uncertainty vector is applied for location reporting to the server node (200).

8. A method according to any of claims 1-7, wherein the current location is obtained from a Global Positioning System. 9. A method according to any of claims 1-8, wherein the mobile client device (202) operates in a travelling vehicle.

10. A mobile client device (702) arranged to report location of the mobile client device (702) to a server node (700), wherein the mobile client device (702) is configured to:

- receive (702A) from the server node (700) an uncertainty vector comprising a required reporting frequency and a maximum permissible travelled distance since a foregoing location report was sent to the server node (700),

- obtain (702B) a current location of the mobile client device (702) when at least one of the reporting frequency and the maximum permissible travelled distance in the uncertainty vector is reached, and - send (702C) a location report with the current location to the server node (700).

11. A mobile client device (702) according to claim 10, wherein the mobile client device (702) is configured to monitor the current location of the mobile client device (702) over time, and to send a next location report to the server node (700) immediately if the monitored current location indicates that a travelled distance since a foregoing location report that was sent to the server node exceeds a threshold relative to a predicted distance derived from the location of said foregoing location report.

12. A mobile client device (702) according to claim 10 or 11, wherein each location report comprises a state vector including values of current location and speed of the mobile client device (702). 13. A mobile client device (702) according to claim 12, wherein the state vector further includes a value of current acceleration of the mobile client device (202).

14. A mobile client device (702) according to claim 12 or 13, wherein the values in the state vector indicate a change of said values since the foregoing location report was sent to the server node.

15. A mobile client device (702) according to any of claims 10-14, wherein the mobile client device (702) is configured to send a next location report to the server node (700) immediately when detecting an exception condition comprising at least one of: a travelled route is blocked or jammed, the mobile client device (702) has stopped, and the mobile client device (702) has changed to a different route.

16. A mobile client device (702) according to any of claims 10-15, wherein the mobile client device (702) is configured to receive an updated uncertainty vector from the server node (700) after at least one location report has been sent to the server node according to the forgoing uncertainty vector, and to apply the updated uncertainty vector for location reporting to the server node (700).

17. A mobile client device (702) according to any of claims 10-16, wherein the mobile client device (702) is configured to obtain the current location from a Global Positioning System.

18. A mobile client device (702) according to any of claims 10-17, wherein the mobile client device (202) is configured to operate in a travelling vehicle.

19. A method performed by a server node (200) for supporting mobility tracking of a mobile client device (202), the method comprising:

- receiving (400, 2: 1) one or more location reports from the mobile client device (202),

- estimating (402, 2:2) a route travelled by the mobile client device (202) based on the received location report(s),

- determining (404, 2:2) an uncertainty vector based on the estimated route, the uncertainty vector comprising a reporting frequency and a maximum permissible travelled distance since a foregoing location report was sent from the mobile client device (202), and

- sending (406, 2:3) the uncertainty vector to the mobile client device (202) as an instruction to apply the uncertainty vector for location reporting.

20. A method according to claim 19, wherein said route is estimated further based on a street network map and a travelling history of the mobile client device (202).

21. A method according to claim 20, wherein said travelling history has been determined based on historical location data previously reported by the mobile client device (202).

22. A method according to claim 21, wherein said travelling history has been determined by applying machine learning on the historical location data.

23. A method according to any of claims 19-22, wherein the uncertainty vector is updated (410, 2:7) based on at least one subsequent location report received (408, 2:6) from the mobile client device (202) after the uncertainty vector was sent to the mobile client device, and the updated uncertainty vector is sent (410, 2:8) to the mobile client device (202) as an instruction to apply the updated uncertainty vector for location reporting.

24. A method according to claim 23, wherein the uncertainty vector is updated by increasing the reporting frequency and/or reducing the maximum permissible travelled distance, when the subsequent location report indicates that the mobile client device (202) approaches a road junction or that the mobile client device (202) has departed from the estimated route.

25. A method according to any of claims 19-24, wherein the server node is implemented as a master server node (800) and a set of local server nodes (800A, 800B) receiving and handling location reports from mobile client devices in respective geographic areas (802A, 802B).

26. A server node (700) arranged to support mobility tracking of a mobile client device (702), wherein the server node (700) is configured to:

- receive (700A) one or more location reports from the mobile client device (702), - estimate (700B) a route travelled by the mobile client device (702) based on the received location report(s), - determine (700C) an uncertainty vector based on the estimated route, the uncertainty vector comprising a reporting frequency and a maximum permissible travelled distance since a foregoing location report was sent from the mobile client device (702), and

- send (700D) the uncertainty vector to the mobile client device (702) as an instruction to apply the uncertainty vector for location reporting.

27. A server node (700) according to claim 26, wherein the server node (700) is configured to estimate said route further based on a street network map and a travelling history of the mobile client device (702).

28. A server node (700) according to claim 27, wherein the server node (700) is configured to determine said travelling history based on historical location data previously reported by the mobile client device (702).

29. A server node (700) according to claim 28, wherein the server node (700) is configured to determine said travelling history by applying machine learning on the historical location data. 30. A server node (700) according to any of claims 26-29, wherein the server node

(700) is configured to update the uncertainty vector based on at least one subsequent location report received from the mobile client device (702) after the uncertainty vector was sent to the mobile client device, and to send the updated uncertainty vector to the mobile client device (702) as an instruction to apply the updated uncertainty vector for location reporting.

31. A server node (700) according to claim 30, wherein the server node (700) is configured to update the uncertainty vector by increasing the reporting frequency and/or reducing the maximum permissible travelled distance, when the subsequent location report indicates that the mobile client device (702) approaches a road junction or that the mobile client device (702) has departed from the estimated route.

32. A server node (700) according to any of claims 26-31, wherein the server node is configured to be implemented as a master server node (800) and a set of local server nodes (800A, 800B) receiving and handling location reports from mobile client devices in respective geographic areas (802A, 802B).

33. A computer program comprising instructions which, when executed on at least one processor, cause the at least one processor to carry out the method according to any one of claims 1-9 or the method according to any one of claims 19-25.

34. A carrier containing the computer program of claim 33, wherein the carrier is one of an electronic signal, optical signal, radio signal, or computer readable storage medium.