WO2018220637A1 - Noeud serveur, dispositif client mobile et procédés pour le rapport de localisation - Google Patents

Noeud serveur, dispositif client mobile et procédés pour le rapport de localisation Download PDF

Info

Publication number
WO2018220637A1
WO2018220637A1 PCT/IN2017/050214 IN2017050214W WO2018220637A1 WO 2018220637 A1 WO2018220637 A1 WO 2018220637A1 IN 2017050214 W IN2017050214 W IN 2017050214W WO 2018220637 A1 WO2018220637 A1 WO 2018220637A1
Authority
WO
WIPO (PCT)
Prior art keywords
mobile client
client device
location
server node
uncertainty
Prior art date
Application number
PCT/IN2017/050214
Other languages
English (en)
Inventor
Sudipta DUTTA
Arindam Banerjee
Arup Kumar Roy
Original Assignee
Telefonaktiebolaget Lm Ericsson (Publ)
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Telefonaktiebolaget Lm Ericsson (Publ) filed Critical Telefonaktiebolaget Lm Ericsson (Publ)
Priority to PCT/IN2017/050214 priority Critical patent/WO2018220637A1/fr
Publication of WO2018220637A1 publication Critical patent/WO2018220637A1/fr

Links

Classifications

    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01C—MEASURING DISTANCES, LEVELS OR BEARINGS; SURVEYING; NAVIGATION; GYROSCOPIC INSTRUMENTS; PHOTOGRAMMETRY OR VIDEOGRAMMETRY
    • G01C21/00—Navigation; Navigational instruments not provided for in groups G01C1/00 - G01C19/00
    • G01C21/26—Navigation; Navigational instruments not provided for in groups G01C1/00 - G01C19/00 specially adapted for navigation in a road network
    • G01C21/34—Route searching; Route guidance
    • G01C21/3453—Special cost functions, i.e. other than distance or default speed limit of road segments
    • G01C21/3492—Special cost functions, i.e. other than distance or default speed limit of road segments employing speed data or traffic data, e.g. real-time or historical
    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01C—MEASURING DISTANCES, LEVELS OR BEARINGS; SURVEYING; NAVIGATION; GYROSCOPIC INSTRUMENTS; PHOTOGRAMMETRY OR VIDEOGRAMMETRY
    • G01C21/00—Navigation; Navigational instruments not provided for in groups G01C1/00 - G01C19/00
    • G01C21/26—Navigation; Navigational instruments not provided for in groups G01C1/00 - G01C19/00 specially adapted for navigation in a road network
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q50/00—Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
    • G06Q50/40—Business processes related to the transportation industry
    • G—PHYSICS
    • G08—SIGNALLING
    • G08G—TRAFFIC CONTROL SYSTEMS
    • G08G1/00—Traffic control systems for road vehicles
    • G08G1/01—Detecting movement of traffic to be counted or controlled
    • G08G1/0104—Measuring and analyzing of parameters relative to traffic conditions
    • G08G1/0108—Measuring and analyzing of parameters relative to traffic conditions based on the source of data
    • G08G1/0112—Measuring and analyzing of parameters relative to traffic conditions based on the source of data from the vehicle, e.g. floating car data [FCD]
    • G—PHYSICS
    • G08—SIGNALLING
    • G08G—TRAFFIC CONTROL SYSTEMS
    • G08G1/00—Traffic control systems for road vehicles
    • G08G1/01—Detecting movement of traffic to be counted or controlled
    • G08G1/0104—Measuring and analyzing of parameters relative to traffic conditions
    • G08G1/0125—Traffic data processing
    • G08G1/0129—Traffic data processing for creating historical data or processing based on historical data
    • G—PHYSICS
    • G08—SIGNALLING
    • G08G—TRAFFIC CONTROL SYSTEMS
    • G08G1/00—Traffic control systems for road vehicles
    • G08G1/20—Monitoring the location of vehicles belonging to a group, e.g. fleet of vehicles, countable or determined number of vehicles

Definitions

  • 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.
  • 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.
  • GPS Global Positioning System
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the following location report(s) may also be equal, as long as the vehicle remains at the same location.
  • reporting frequency 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.
  • frequent sending of location reports consumes energy on the transmitting side so that a battery in the device may be drained in short time.
  • 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.
  • a method is performed by a mobile client device for reporting location of the mobile client device to a server node.
  • 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.
  • 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.
  • a method is performed by a server node for supporting mobility tracking of a mobile client device.
  • 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.
  • 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.
  • 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.
  • 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
  • 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.
  • 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.
  • 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 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.
  • the mobile client device may send an "early" location report well before any of the parameters in the uncertainty vector has been reached.
  • a server node 200 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the mobile client device 202 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • a mobile client device such as the above-described mobile client device 202.
  • Fig. 3 is described below with further reference to Fig. 2.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the size of the communicated information may be minimized or at least reduced as compared to reporting the full absolute values.
  • 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.
  • 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.
  • 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.
  • the server node 200 may 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the current location may be obtained from a Global Positioning System, GPS, function which is employed at the mobile client device 202.
  • GPS Global Positioning System
  • 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.
  • 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.
  • 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.
  • 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.
  • said travelling history may in that case have been determined based on historical location data previously reported by the mobile client device 202.
  • the travelling history may 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • FIG. 5 thus illustrates some useful actions that may be performed by the above-described mobile client device 202.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the server node 200 receives one or more location reports from the mobile client device 202, which corresponds to action 400.
  • the location report(s) may be sent from the device 202 according to a regular scheme or according to a previously provided uncertainty vector.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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).
  • ASIC Application Specific Integrated Circuit
  • 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.
  • 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.
  • 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”
  • 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”.
  • 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:
  • 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.
  • Uncertainty reactor sends the location data to the server node as per the trigger of predefined uncertainty received from data transmission policy handler.
  • 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.
  • 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.
  • 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.
  • DES Double Exponential Smoothing
  • 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.
  • 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.
  • M2M Machine-to-Machine
  • MQTT Message Queue Telemetry Transport MQTT
  • Hypertext Transfer Protocol HTTP Hypertext Transfer Protocol
  • 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 JSON format that holds probable distance of the client with adaptive reporting frequency.
  • 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.
  • s 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.
  • Response is sent from server node to client in below J SON format.
  • 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 ⁇ ! 3 ⁇ 4 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 2 ), (n 3 , n 4 ), ... , (nd-i, nd) represented as a sequence of vertices ... 3 ⁇ 4 . , ⁇ .
  • 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.
  • Each vertex has its own location data
  • the mobile client device may perform the following basic steps to reach a destination: 1. Determine the destination.
  • 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.
  • the street network matrix generator shown in Fig. 10 stores some associated matrices in a database, such as:
  • Street matrix 5
  • Connectivity matrix C for connectivity having dimension of n x n that holds the information of connections among streets (or lanes),
  • 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.
  • 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") ⁇ .
  • probe frequency some M2M communication protocol at regular intervals
  • 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 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.
  • a location report
  • the mobile client device 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.
  • 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.
  • 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 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.
  • 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.
  • the server node 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.
  • regular frequency probe frequency
  • the location data can be treated as outliers and alarm event generated.
  • the alarm can trigger manual intervention from City Chrysler body or to Road Transport Authority Body.
  • the reporting frequency of location reporting should be set so that the mobile client device sends location reports adaptively.
  • the frequency of location reporting from the mobile client device can be decreased.
  • 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.
  • the mobile client device's GPS location data is sent in a location report again to the server node.
  • Time To First Fix 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:
  • trajectory estimation 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 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:
  • An uncertainty region of a mobile client device at time 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:
  • 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.
  • 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.
  • the mobile client device may be equipped with GPS sensor. It may also have optional speed data (OBD).
  • OBD speed data
  • 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.
  • a state vector consisting of three parameters is considered including location, velocity and acceleration (optional) of the mobile client devices.
  • 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.
  • DES Double Exponential Smoothing
  • the term ⁇ s t ⁇ is used to represent the smoothed value for time t
  • the term ⁇ b t ⁇ is a smoothed trend value at time t.
  • a e [0,1) is the data smoothing factor
  • ⁇ 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).
  • F s ⁇ . (S t - rb s ⁇ - f 5 s 3 It was mentioned above that ⁇ and ⁇ 2 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 ⁇ 2 as 0 since road type matrix does not hold historical acceleration and historical speed values are not stored for new trajectory.
  • 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.
  • IoT Internet of Things
  • MQTT is ideal for large networks of small devices that need to be monitored or controlled from a back-end server on the Internet.
  • 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.

Landscapes

  • Engineering & Computer Science (AREA)
  • Radar, Positioning & Navigation (AREA)
  • Remote Sensing (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Automation & Control Theory (AREA)
  • Chemical & Material Sciences (AREA)
  • Analytical Chemistry (AREA)
  • Business, Economics & Management (AREA)
  • Economics (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Human Resources & Organizations (AREA)
  • Marketing (AREA)
  • Primary Health Care (AREA)
  • Strategic Management (AREA)
  • Tourism & Hospitality (AREA)
  • General Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

L'invention concerne un dispositif client mobile (202), un noeud serveur (200) et des procédés à l'intérieur de celui-ci, pour rapporter la localisation du dispositif client mobile (202) et pour la prise en charge du suivi de mobilité du dispositif client mobile (202). Le noeud serveur (200) estime (2:1, 2:2) un itinéraire parcouru par le dispositif client mobile (202) et détermine (2:2) un vecteur d'incertitude sur la base de l'itinéraire estimé. Le vecteur d'incertitude comporte une fréquence de rapport requise et une distance parcourue admissible maximale d'un rapport de localisation précédent. Le vecteur d'incertitude est transmis au dispositif client mobile (202) sous forme d'une instruction de rapport de localisation. Le dispositif client mobile (202) applique ensuite (2:4) le vecteur d'incertitude pour un rapport de localisation de sorte que lorsqu'une parmi ladite fréquence de rapport et la distance parcourue maximale autorisée est atteinte (2:5), le dispositif client mobile (202) obtient sa localisation courante et transmet (2:6) un rapport de localisation en conséquence au noeud serveur (200).
PCT/IN2017/050214 2017-05-31 2017-05-31 Noeud serveur, dispositif client mobile et procédés pour le rapport de localisation WO2018220637A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/IN2017/050214 WO2018220637A1 (fr) 2017-05-31 2017-05-31 Noeud serveur, dispositif client mobile et procédés pour le rapport de localisation

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/IN2017/050214 WO2018220637A1 (fr) 2017-05-31 2017-05-31 Noeud serveur, dispositif client mobile et procédés pour le rapport de localisation

Publications (1)

Publication Number Publication Date
WO2018220637A1 true WO2018220637A1 (fr) 2018-12-06

Family

ID=64455770

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/IN2017/050214 WO2018220637A1 (fr) 2017-05-31 2017-05-31 Noeud serveur, dispositif client mobile et procédés pour le rapport de localisation

Country Status (1)

Country Link
WO (1) WO2018220637A1 (fr)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2022011704A1 (fr) * 2020-07-17 2022-01-20 北京小米移动软件有限公司 Procédé et dispositif de signalement de mesures de localisation, terminal et support de stockage
WO2022106015A1 (fr) * 2020-11-19 2022-05-27 Telefonaktiebolaget Lm Ericsson (Publ) Sélection d'un ou plusieurs faisceaux pour la communication et/ou la mesure, ou détermination du mouvement d'un dispositif sans fil
US20220171404A1 (en) * 2019-03-29 2022-06-02 Zoox, Inc. Techniques for authorizing vehicle control systems
WO2023143808A1 (fr) * 2022-01-26 2023-08-03 British Telecommunications Public Limited Company Réseau de télécommunications sans fil
EP4280637A4 (fr) * 2021-01-14 2024-07-24 Lg Electronics Inc Procédé de transmission d'un message par un terminal v2x dans un système de communication sans fil et dispositif associé

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20160234647A1 (en) * 2015-02-06 2016-08-11 Ping4 Inc. Method for optimizing battery use in a mobile device while tracking a location of the device

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20160234647A1 (en) * 2015-02-06 2016-08-11 Ping4 Inc. Method for optimizing battery use in a mobile device while tracking a location of the device

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
"Terrestrial Trunked Radio (TETRA); Voice plus Data (V+D) and Direct Mode Operation (DMO); Part 18: Air interface optimized applications; Sub-part 1: Location Information Protocol (LIP", ETSI TS 100 392-18 -1, April 2007 (2007-04-01), SOPHIA ANTIPOLIS CEDEX, FRANCE, XP055556819, [retrieved on 20070400] *

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20220171404A1 (en) * 2019-03-29 2022-06-02 Zoox, Inc. Techniques for authorizing vehicle control systems
WO2022011704A1 (fr) * 2020-07-17 2022-01-20 北京小米移动软件有限公司 Procédé et dispositif de signalement de mesures de localisation, terminal et support de stockage
WO2022106015A1 (fr) * 2020-11-19 2022-05-27 Telefonaktiebolaget Lm Ericsson (Publ) Sélection d'un ou plusieurs faisceaux pour la communication et/ou la mesure, ou détermination du mouvement d'un dispositif sans fil
EP4280637A4 (fr) * 2021-01-14 2024-07-24 Lg Electronics Inc Procédé de transmission d'un message par un terminal v2x dans un système de communication sans fil et dispositif associé
WO2023143808A1 (fr) * 2022-01-26 2023-08-03 British Telecommunications Public Limited Company Réseau de télécommunications sans fil

Similar Documents

Publication Publication Date Title
WO2018220637A1 (fr) Noeud serveur, dispositif client mobile et procédés pour le rapport de localisation
CN110447245B (zh) V2v分簇和多跳通信
US11653222B2 (en) Optimizing wireless networking using a virtual geographic information system overlay
EP3949459B1 (fr) Découpage en tranches de nuage véhiculaire
Ansari Cooperative position prediction: Beyond vehicle-to-vehicle relative positioning
Nguyen et al. Car-to-Pedestrian communication with MEC-support for adaptive safety of Vulnerable Road Users
KR101495456B1 (ko) 무선국의 셀프-포지셔닝
US10243717B2 (en) Service, wireless device, methods and computer programs
JP2020140704A (ja) 車両マイクロクラウドによる異常マッピング
CN113906716A (zh) 雾节点资源的分配
Chavhan et al. An efficient context-aware vehicle incidents route service management for intelligent transport system
EP3955644B1 (fr) Dispositif de traitement d'informations, procédé de traitement d'informations et serveur
Liu et al. A novel energy-saving one-sided synchronous two-way ranging algorithm for vehicular positioning
US20230008967A1 (en) Methods of communication in traffic intersection management
CN105338466A (zh) 位置信息获取方法及设备
US20230059588A1 (en) Vehicle position estimation
JP2023517389A (ja) 地図データ収集方法および装置、ならびにシステム
Figueiredo et al. Mobility sensing and V2X communication for emergency services
EP3837494B1 (fr) Détection de localisation multimodale sur un téléphone mobile
CN116222600A (zh) 一种智能车多目标路径规划方法、系统、介质及终端
KR20180069592A (ko) 위치 추정 시스템 및 그것의 동작 방법
US10546307B2 (en) Method, apparatuses, and computer program products for automatically detecting levels of user dissatisfaction with transportation routes
CN114363308A (zh) 一种地图数据的传输方法及装置
US12096280B2 (en) System and a method for increasing network efficiency in a 5G-V2X network
US11233717B2 (en) System and method for collaborative centralized latency characterization

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 17911531

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 17911531

Country of ref document: EP

Kind code of ref document: A1