WO2017180382A1

WO2017180382A1 - System and method for data validation in a decentralized sensor network

Info

Publication number: WO2017180382A1
Application number: PCT/US2017/026082
Authority: WO
Inventors: Pasi Sakari Ojala; Samian Kaur; Alexander Reznik
Original assignee: PCMS Holdings Inc
Current assignee: PCMS Holdings Inc
Priority date: 2016-04-12
Filing date: 2017-04-05
Publication date: 2017-10-19
Anticipated expiration: 2018-10-12

Abstract

Systems and methods related to data validation in decentralized sensor networks. Exemplary embodiments use local identification tokens (LITs) together with storing data in local infrastructure as local instances of a database. A peer network may comprise sensor nodes and local infrastructure handling data relevant to a local area. A vehicle may connect to the closest infrastructure node in a peer network. The vehicle downloads the corresponding database for navigation. A vehicle sensor detects a new event such as a new traffic sign, and creates a measurement transaction. Another vehicle entering the road segment may connect to the local infrastructure node, and receive the new open transaction and associated Local Identification Token. Data from the second vehicle's sensors is uploaded. The sensor node LIT is provided to downstream infrastructure equipment, which in turn validates the LIT and correlates the measurements to determine if the measurement report is validated.

Description

SYSTEM AND METHOD FOR DATA VALIDATION IN

A DECENTRALIZED SENSOR NETWORK

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] The present application is a non-provisional filing of, and claims benefit under 35 U.S.C. §119(c) from, U.S. Provisional Patent Application Serial No. 62/321,462, filed April 12, 2016, entitled "System and Method for Data Validation in a Decentralized Sensor Network," the entirety of which is incorporated herein by reference.

BACKGROUND

[0002] Social media services, cloud-based data storage services, online retailers, transportation or resource sharing networks, and mapping services collect user data regarding the service usage and related contextual information in their own servers in their own cloud service. These services benefit from the network effect when all the user data is centralized in one place and the data can be utilized to further improve the service. Maps are enhanced when users share location-based information, and recommendation engines learn new profiles when people are busy using the services. In addition, when users share information with each other, such centralized services collect valuable information and connections which are then leveraged for developing new value-added service features. An interesting domain is the autonomous driving and navigation services. In such services, cloud based services are utilized that store both the user generated mapping data and traffic related information in their own databases.

[0003] One organization, the Crash Avoidance Metrics Partnership (CAMP), founded by Ford and GM, is working with sensor fusion by combining data from neighbors and high fidelity mapping. The concept is to crowd-source the data collection to individual vehicles. The target of the work is on vehicle safety communications and security protocols.

[0004] In order for a self-driving car to operate most effectively, the roadway model upon which it relies should be sufficiently up-to-date. For example, if the position of a highway on-ramp or off-ramp in the real-world roadway has changed but the roadway model does not reflect this change, a self-driving road vehicle may be unable to navigate from or to the ramp. Even less significant changes or discrepancies, such as potholes or temporary obstacles on the road can impede the performance of a self-driving vehicle.

[0005] Thus, it is important that the roadway model be kept up to date. However, there are several challenges in maintaining an up-to-date roadway information. [0006] In a cloud-based approach, updating a roadway model requires traversing the roadway with a "test" sensor-laden vehicle. This can be a very expensive process for a roadway that comprises extensive network of roads.

[0007] Furthermore, maintaining all information in a central cloud requires transactions with the cloud and uses bandwidth (e.g., uploading LiDAR measurements, high resolution camera images, etc.). Temporary obstacles may be dynamic and uploading discrepancies to the cloud may not be efficient in terms of latency. The discrepancy information may also become obsolete quickly and not too useful due to the latency of the transactions with a cloud-based server.

[0008] Cloud-based systems can be a single point of security failure, and can be compromised by input from fake users. Incidents of misuse have been reported in cloud based navigation systems by hackers creating active fake users that report traffic jams, causing rerouting and potentially long hours of traffic jams.

[0009] To resolve some of these concerns, there are proposals to provide certificates to vehicles, and to only allow inputs into the cloud servers from certified users. When only certified nodes are allowed to contribute to measurement task, all nodes need to be cross-checked to make sure they are reporting accurate information. Further, any node reporting false information needs to be detected and the misbehavior reported. However, providing certificates to all vehicles does not guarantee that the contributed data is correct unless it is verified by other network nodes. In addition, a certification does not prevent a node from inserting false data in the database time line unless there is a verification mechanism and ways to prevent database modifications. For example, even a certified sensor or the user of the certified sensor could add a false measurement phenomenon or data report, such as a detection of slippery road conditions in a certain location within a certain time window. This could have a significant effect on some situations, such as investigations conducted by an insurance company.

SUMMARY

[0010] In an exemplary method, a start-marker road-side unit (RSU) is positioned at an start of a road segment and an end-marker road-side unit (RSU) is positioned at an end of the road segment. The start-marker RSU transmits local identification tokens (LITs) to passing vehicles before they traverse the road segment. The vehicles collect data on the road segment as they traverse the segment and generate measurement records based on the collected data. The end- marker RSU receives measurement records from the vehicles that have traversed the road segment. The measurement records include a respective local identification tokens. The end-marker RSU operates to validate the local identification tokens to determine whether those tokens were issued by the appropriate start-marker RSU. The end-marker RSU further operates to determine whether a sufficient number of these measurement records report a common discrepancy in a condition of the road segment as compared to map data of the road segment (e.g. a sufficient number or records report a pothole in substantially the same location, or a sufficient number of records reflect that an obstacle present in map data is no longer on the road). If a threshold number (e.g. at least two) records report the same discrepancy, at least one of the RSUs updates map data consistent with the measurement records to reflect the reported discrepancy.

[0011] In some embodiments, the start-marker RSU provides local map data to vehicles before they traverse the road segment. The map data provided to those vehicles may be updated in response to a sufficient number of measurement records (with valid local identification tokens) reporting a discrepancy.

[0012] In some embodiments, in response to the end-marker RSU receiving a measurement record that reports a discrepancy, the end-marker RSU reports that measurement record to the start-marker RSU. The start-marker RSU considers the report to be "open" (not yet confirmed). In response to creation of the open report, the start-marker RSU transmits to vehicles entering the road segment: (i) a request to confirm the discrepancy and (ii) a respective local identification token.

[0013] Generation and validation of a local identification token may be performed using one or more of various techniques, such as use of a hash chain. In some embodiments, measurement records are validated using a blockchain mechanism.

BRIEF DESCRIPTION OF THE DRAWINGS

[0014] A more detailed understanding may be had from the following description, presented by way of example in conjunction with the accompanying drawings, wherein:

[0015] FIG. 1 is a schematic diagram of one embodiment of a method of data validation in a decentralized sensor network.

[0016] FIG. 2 is a flow block diagram of one embodiment of a measurement conducted by an individual sensor node being validated by the peer network of other sensor nodes and added to a database.

[0017] FIGs. 3 A-3C are a sequence diagram of one embodiment of a method of data validation in a decentralized sensor network.

[0018] FIG. 4 depicts an exemplary reverse hash chain (RHC).

[0019] FIG. 5 is a flow block diagram of one embodiment of a method of data validation using a blockchain mechanism. [0020] FIG. 6 illustrates an exemplary wireless transmit/receive unit (WTRU) that may be employed as a vehicular communication system or a road-side unit in some embodiments.

[0021] FIG. 7 illustrates an exemplary network entity that may be employed in some embodiments, for example as a map server or road-side unit.

DETAILED DESCRIPTION

[0022] A detailed description of illustrative embodiments will now be provided with reference to the various Figures. Although this description provides detailed examples of possible implementations, it should be noted that the provided details are intended to be by way of example and in no way limit the scope of the application.

[0023] Note that various hardware elements of one or more of the described embodiments are referred to as "modules" that carry out (i.e., perform, execute, and the like) various functions that are described herein in connection with the respective modules. As used herein, a module includes hardware (e.g., one or more processors, one or more microprocessors, one or more microcontrollers, one or more microchips, one or more application-specific integrated circuits (ASICs), one or more field programmable gate arrays (FPGAs), one or more memory devices) deemed suitable by those of skill in the relevant art for a given implementation. Each described module may also include instructions executable for carrying out the one or more functions described as being carried out by the respective module, and it is noted that those instructions could take the form of or include hardware (i.e., hardwired) instructions, firmware instructions, software instructions, and/or the like, and may be stored in any suitable non-transitory computer- readable medium or media, such as commonly referred to as RAM, ROM, etc.

Exemplary Systems and Methods.

[0024] Described herein are systems and methods in which a sensor network captures, stores, and distributes sensor data in a decentralized manner without an external trusted control and service provider. Each network node may independently collect information, which may be distributed to the network after it has been validated by the peer group using localized validation algorithms.

[0025] In order for a self-driving car to operate effectively, the roadway model upon which it relies should be sufficiently up-to-date. For example, if the position of a highway on-ramp or off- ramp on the real-world roadway has changed but the roadway model does not reflect this change, a self-driving road vehicle may be unable to navigate from or to the ramp. Even less significant changes or discrepancies, such as potholes or temporary obstacles on the road can impede the performance of a self-driving vehicle. [0026] Thus, it is important that the roadway model be kept up to date.

[0027] The present disclosure describes deployment of infrastructure markers or road side units (RSUs) along a route, which are capable of receiving and transmitting data with vehicles along the route in a given direction. A route may be logically split into multiple road segments, wherein each road segment may be bookended with an RSU at the start and end of a road segment (such as mile markers on a highway, or stop signs along blocks). The infrastructure elements are able to communicate with each other and transfer information upstream (along the direction of traffic) and downstream (in the opposite direction of traffic).

[0028] An overview of an exemplary embodiment is explained with reference to FIG. 1 as a vehicle traverses a road segment 102 between RSUs 104 and 106. As the vehicle enters the road segment, at position 108, the start-marker RSU 104 provides the vehicle with a message which may contain map information for the upcoming road segment (optional), identifier information that identifies RSU 104, and a locally generated token or hash token or nonce token. This information is referred to herein as a Local Identification Token (LIT). In some embodiments, the message may contain additional pieces of information.

[0029] As the vehicle continues to traverse the road segment 102, at position 110 the vehicle detects an anomaly or discrepancy between the information in its stored 3-D map and what is actually observed on the road as the vehicle drives on the road segment, such as a pothole 112 that has appeared since the map was last updated. The vehicle creates a measurement record with the location of the problem (e.g. of pothole 112), vehicle sensor measurements, start-marker RSU identification information, and the Local Identification Token. Examples of discrepancies may include a change in road condition (such as potholes, etc.), debris on the road, construction related vehicles or markers on the road, a traffic sign that is new or that is removed, and/or the like.

[0030] The vehicle continues to traverse the road segment 102 and at position 114 reaches a second RSU along the route, end-marker RSU 106. The vehicle may transmit its measurement record, including the LIT, to that RSU 106. The end-marker RSU may determine the relevant start- marker RSU from the identification provided in the measurement record (such as the LIT), and may forward the record to start-marker RSU 104. The start-marker RSU 104 may validate the LIT information, and may store this information as an open (e.g., not yet validated) measurement record.

[0031] At some later time, a second vehicle may approach the start of the road segment, and along with an LIT the second vehicle may be provided by start-marker RSU 104 with a query related to all open (e.g., not yet validated) measurement records at the start-marker RSU 104. The query may in some embodiments be an explicit request to confirm the location and measurement of a record. In another embodiment, the request may be an implicit request for the second vehicle to perform measurements at certain GPS coordinates and provide a report to the end-marker RSU 106.

[0032] The second vehicle may perform measurements as per the query request and may upload them along with the associated identification and LIT information to the end-marker RSU 106. Again, the end-marker RSU 106 may determine the relevant start-marker RSU 104 and forward the record to the start-marker RSU. Communications between start and end RSUs may be performed directly or through a network. In some embodiments, the network includes a mapping server 116, which may store validated and open measurement records, seek validation for open records, and update a map according to validated measurement records.

[0033] In response to the start-marker RSU 104 confirming a preset number of measurements (e.g. 2 measurements of the same feature), the measurement record may be validated and a map database maintained by mapping server 116 and/or by the RSUs may be updated accordingly.

[0034] The updated map information may be provided to all vehicles taking the road segment, as needed. In various embodiments, the map database may be centrally deployed as a cloud server 116, or distributed and provided for road segments as needed by RSUs.

[0035] In some embodiments, modifications may be performed to reduce the overhead of the message exchange. In one embodiment, the LIT generated by the start-marker RSU 104 may use a reverse-hash chain algorithm, such that the end-marker RSU 106 may independently perform the validation and update the map database. Further description is provided below.

[0036] In another embodiment, the LIT may be generated using local channel conditions at the start-marker RSU 104 at the time of generation, and each vehicle may be provided with a timestamp along with an LIT. This may ensure the disclosed method is resistant to replay attack, since the local channel conditions are constantly changing, and the start-marker RSU 104 may validate reported measurements using the timestamps associated with the reported LITs.

[0037] In another embodiment, the start-marker RSU 104 may maintain a buffer of previously generated LITs, and confirm a reported LIT without obtaining a timestamp directly from the vehicle.

[0038] In some embodiments, start-marker and end-marker RSUs are interchangeable, such that an RSU that acts as a start-marker with respect to a vehicle traveling in one direction acts as an end-marker with respect to a vehicle traveling in the opposite direction.

[0039] One advantage of at least some of the disclosed methods is improved robustness against a hacker who might report false information about roadway conditions and/or traffic information, such as to re-direct traffic or generally create havoc for nefarious purposes. The disclosed methods may ensure all information is validated as having been generated locally, and thus increases the difficulty for a hacker to create false identities and make reports over an internet link to the map database in the cloud.

[0040] In some embodiments, the disclosed methods may rely on a peer-to-peer network to enable reliable sensor data validation and data distribution among the network nodes, even when the nodes do not have trust. In some embodiments, the reporting and data capture can be performed anonymously within the network. The trust may be based on peer network nodes conducting the verification and checking the integrity of the database using localized tokens.

[0041] Another feature of at least some of the disclosed methods is support for sensor validation and for ways to automatically detect and discard outlier readings, for example, due to some vehicle sensors not working properly. In one embodiment, this system and/or method monitors for outlier readings and informs vehicles of a need to have their associated sensors inspected. This information may be provided if the vehicle identification is available, and the vehicle can be reached at a later time when sufficient readings are available to assess outliers.

[0042] Another feature of at least some of the disclosed methods is facilitating the deployment of a distributed map database, such that vehicles may receive the most up-to-date map database from the RSUs on as-needed basis. Such embodiments may have advantages over solutions that rely on central map databases.

[0043] In one embodiment, the present disclosure relates to a method of using a Local Identification Token (LIT).

[0044] Collecting all the traffic and contextual sensor data in a peer network may increase the database size without any limitations. Having global data decentralized in each network node may not be feasible. In one embodiment, data is stored in a local infrastructure as local instances of the database. The peer network may comprise wireless sensor nodes (of distinct autonomous vehicles) and a local infrastructure handling the data relevant to a local area. Hence, the network may combine the mobile sensors and local databases. In some embodiments, the infrastructure nodes are similar to the wireless nodes with the same protocols and same level of trust. Infrastructure nodes may also perform measurements and create measurement transactions. Their function may be to handle local data and accept new transactions only from the neighborhood. Hence, the database may contain only local data.

[0045] Local databases may be established along various highway and street networks. For example, a lamp post may host a peer network node that maintains a distributed database instance for traffic and mapping data of that area. [0046] Autonomous vehicles may always be connected at least to the closest infrastructure node, and download the corresponding database instance in their own storage. In some embodiments, when vehicles make new measurements, they share the data to one or more of the closest infrastructure nodes. Hence, each local distributed database will specialize to their own environment.

[0047] An exemplary data contribution process is described in more detail with respect to FIG. 2, which is a schematic diagram depicting an embodiment of a method of data validation in a decentralized sensor network. An autonomous vehicle or other sensor enabled vehicle (first sensor node 202) may be connected to a closest infrastructure node in a peer network 204. The sensor node 202 detects a discrepancy between map data of a road segment and reports the discrepancy to a node in the peer network 204. The node in the peer network 204 generates an open discrepancy record 206 and uploads it to the next infrastructure element (IE). The infrastructure element conveys the open discrepancy record to other nodes 208a, 208b, 208c, which may be vehicles entering the same road segment as sensor node 202. In response to receiving the open discrepancy record, one or more of the sensor nodes 208a, 208b, 208c perform measurements of the road segment and upload the measurements along with a localized identification token (LIT). In response to a sufficient number of nodes with a valid LIT reporting consistent measurements to an IE, the transaction is considered validated 210. The validated transaction is reported to local nodes (e.g. RSUs) and is stored as respective localized discrepancy records 212a, 212b, 212c. These localized discrepancy records may be provided wirelessly to vehicles entering the road segment at issue such that those vehicles have updated information on the condition of that road segment.

[0048] In some embodiments, a vehicle may have downloaded a corresponding database for navigation purposes. In response to detection by the first sensor node of a new event, such as a new traffic sign, the first sensor node may create a measurement transaction. Later, a second vehicle (second sensor node) entering the road segment may be connected to the local infrastructure node, and receive the new open transaction and associated Local Identification Token. After the second vehicle has traveled the road segment, the data from the second sensor node may be uploaded, and the sensor node LIT may be provided to a downstream infrastructure element (IE). The downstream IE may in turn validate the LIT, and correlate the measurements to determine if the measurement report should be validated or invalidated.

[0049] FIGs. 3A-3C depict a sequence diagram of an exemplary embodiment of the method described above. [0050] As illustrated in FIG. 3A, on approaching or entering into a road segment starting at

Mile 59, Car A (302) may receive from a start RSU 304 a data message, such as including an up- to-date map, an LIT, an RSU ID, a timestamp, and the like (step 305). In some embodiments, fewer than these elements may be received. As Car A drives along road segment Mile 59, Car A's sensors may detect a pothole and perform measurements to log the detection (step 306). In some embodiments, Car A may have received information regarding open transactions at the start RSU, and can compare the measurement data to those transactions (step 308). If there is no match, Car A may create a new transaction entry including relevant measurements, timestamps, LIT, and the like. In some embodiments, Car A may not have received any open transactions, and may create a new transaction entry for any appropriate detection event.

[0051] Car A may continue traveling and approach a stop RSU for road segment Mile 59. Car A may communicate with the stop RSU so as to report the new transaction for the pothole, where the reported transaction may include, for example and without limitation, the Car A measurement data, GPS location of the pothole, a Car A signature or ID, and the like (step 312). The stop RSU 310 may receive the report and record the open transaction (step 314). In some embodiments, Car A may also broadcast the new transaction as an open transaction in a vehicle to vehicle (V2V) message (step 316) to other enabled vehicles within communication range. In some embodiments, the broadcast transaction may include, for example and without limitation, the Car A measurement data, GPS location of the pothole, a Car A signature or ID, and the like. Through the process discussed above, the stop RSU may forward the transaction to the start RSU (step 318).

[0052] As illustrated in FIG. 3B, at some later time, on approaching or entering into road segment Mile 59 (step 321), Car B (320) may receive (in step 322) from the start RSU 304 a data message, such as a message including an up-to-date map, an LIT, an RSU ID, a timestamp, etc., as well as open transactions (e.g., the one just created by Car A). Car B may record open transaction identified in the message(s) from the start RSU (step 324). Car B may then drive along road segment Mile 59, and detect the same pothole (step 326), performing measurements when detected. Car B may then compare the measurements against the open transactions (step 328), which include the transaction for the pothole generated by Car A. Because these are the same pothole, Car B is able to confirm or validate the open transaction. In one embodiment, Car B may report the validated transaction (step 330) to the stop RSU 310 on approaching or passing the stop RSU. The reported validated transaction may include Car B measurement data, GPS location of the pothole, Car B signature or ID, and the like. [0053] As above, the stop RSU may forward the transaction(s) to the start RSU (step 332). At the start RSU 304, the open transaction created by Car A may be marked as validated (step 334) in light of the validation report from Car B.

[0054] As illustrated in FIG. 3C, at some later time, on approaching or entering into road segment Mile 59, Car C (336) may enter Mile 59 (step 338) and receive from the start RSU in step 340) a data message, such as a message including an up-to-date map, an LIT, an RSU ID, a timestamp, and the like, as well as validated transactions (e.g., the one just created by Car A and validated by Car B). Car C may then, to its local data, add the pothole transaction as a validated transaction (step 342), and proceed to use this validated information to operate a routing algorithm if necessary (or check whether a new route is optimal given the validated information). In some other embodiments, the validated information may be used in other ways.

[0055] In one embodiment, the present disclosure relates to a method of using a reverse hash chain to assist in validation of data measurements.

[0056] Some exemplary embodiments make use of a pre-established trusted link between the RSUs that is protected from tampering. Various techniques for providing a trusted link may be used.

[0057] In one embodiment of a method of the present disclosure, the Local Identification Token may be generated at the start-marker RSU using a one-way hash function. A hash chain is the successive application of a cryptographic hash function to a piece of data. For non-repudiation, a hash function can be applied successively to additional pieces of data in order to record the chronology of the data's existence.

[0058] FIG. 4 depicts an exemplary embodiment of a reverse hash chain (RHC).

[0059] For a given measurement record, the start-marker RSU may pre-generate the following tokens by repeated hashing of an initial seed Vo, and use Vi as an LIT.

[0060] A reverse hash chain (RHC) is a pre-generated sequence of hash function V_t = ^0¾-_ΐ})_> where h( ) is a cryptographically secure hash. The chain is initiated using an arbitrary starting point Vo. A fixed number N of link elements is generated such that the chain stops at VN. One property of a hash chain is that given three indices 0≤i < j < k≤N, and given Vj, it is relatively easy to compute Vk, but quite hard (or computationally infeasible) to compute Vi. Essentially, the chain can be computed forward but not backwards.

[0061] For every measurement to be validated, a RHC may be generated using a different starting value. The value may be generated randomly, or based on the measurement or other values. The length of the chain N may depend on policy, the nature and type of measurement to be validated, or other aspects. When a car passes and no measurement needs to be validated, the car may be provided with an LIT of VN, or the car may be provided with nothing. Once a measurement is to be validated, each car may be provided a hash V, from the RHC in reverse order (thus "reverse" hash chain) - starting with VN, then V(N-I), V(N-2), (if V(N> is provided before validation, then start with V(N-I>) and so on until Vo. The car may also be provided with an index of the hash (e.g., i for Vi). The cars may report the measurement(s) back and include their respective Vi and their respective index i in the reporting. Once Vo is received, the system can validate the chain by re-computing it from Vo and confirming that the re-computation matches.

[0062] In some embodiments, such re-computation may occur at the receiving station (such as a stop RSU), rather than an originating station (e.g., start RSU). Accordingly, the need for communicating all validation reports back may be eliminated. In some embodiments, only the initial measurement to be validated may need to be reported back to an originating station (so that the originating station can start the count-down of the RHC).

[0063] In one embodiment, the present disclosure relates to data validation processes using a blockchain mechanism. FIG. 5 depicts a flow block diagram of one embodiment of a method of data validation using a blockchain mechanism. In some embodiments, a vehicle conducting a measurement (step 502) may create an open measurement transaction block and broadcast it to a peer network (step 504).

[0064] Each network node may receive and validate (step 506) the broadcast transaction and verify the measurement by duplicating the result. In some embodiments, only the network nodes within the neighborhood may be activated for the task. After duplicating the result, the verifying nodes may attempt to solve the "proof-of-work" by connecting the transaction to the blockchain as a measurement transaction block and finding the solution to the hash function (step 508).

[0065] In some embodiments, the "proof-of-work" difficulty level is adapted based on the network node population within the region or neighborhood. As the task becomes more difficult, finding the solution may on average take a longer time during which more nodes may become available.

[0066] The first node that manages to complete the verification and "proof-of-work" may broadcast the validated transaction to the peer network in the region or neighborhood (step 510).

[0067] Each nearby node may pick up the validated block or transaction and check that the hash function fits with the blockchain (step 512). Again, the validated block may be distributed only within a closed geographical area around the measurement location (e.g., region or neighborhood). If the hash function is correct, each node may add the transaction block in its respective blockchain. [0068] As data entries have location information, the decentralized database managed by individual nodes may be split into local instances that handle only the data collected within the given area (e.g., region or neighborhood). Peer network nodes may handle the local instances similarly to the global database. In some embodiments, only the nodes within a predetermined distance (e.g., the nodes that are closest to the mobile network node that is issuing an open measurement transaction) may handle the operation and accept the new entry in their blockchain instances. In some instances, a blockchain approach may ensure that the local database requested from the desired area is valid and unmodified. The peer network may operate to verify the integrity at all times.

[0069] In some embodiments, network nodes may parse the data entries in their blockchain into other structures, such as a SQL based database, to enable easy access and search.

[0070] In some embodiments, the content of messages or reports communicated or passed between vehicles, RSUs, and others may comprise various different details or information.

[0071] In one embodiment, a measurement transaction may comprise a message or report of a sensor measurement. For example, a mobile sensor network node may be tasked to make measurements and detect the environment while it moves or in some instances only at predetermined locations. When a new measurement is available, the node (e.g., a sensor of a vehicle) may assign a measurement transaction that is transmitted to an upcoming or nearby RSU.

[0072] Table 1 depicts an exemplary embodiment of a measurement transaction data structure, with its various data fields. In one embodiment, the measurement transaction package distributed over the network may contain the actual measurement in the data field, any protocol details, a timestamp corresponding to the start time of a measurement or detection, and a location of the measurement (e.g., in GPS coordinates). In some embodiments, additional or fewer fields may be included in a transaction message.

Protocol Details, version

Timestamp (start time of measurement)

Location (GPS coordinates)

Measurement data field

Table 1.

[0073] Table 2 depicts an exemplary embodiment of a measurement data field which may be included in the data structure as illustrated in Table 1. In one embodiment, the actual data field of the transaction package may contain any sensor modality, continuous signal, or status message. In one embodiment, the details in the structure may be coded in a transaction packet as one single row. In one embodiment, the number of bytes for each data item may be fixed.

[0074] In some embodiments, the network(s) may generate pools or lists or measurement transaction messages or reports. In some embodiments, a node may make a new measurement, issue a new transaction, and upload that transaction to an infrastructure element (e.g., RSU). At later times, when any other nodes (e.g., cars) get close to the road segment where the new measurement was conducted, such node(s) may be asked to participate in the verification task, such as by being requested to measure the discrepancy at a provided location, along with a LIT. In some embodiments, the LIT may be a nonce, or a key generated using the physical channel between the RSU and the sensor node.

[0075] In some embodiments, each transaction may be anonymous. For example, based on the data fields discussed above, a network node may have information identifying the specific user or application which created the transaction.

[0076] Table 3 illustrates an exemplary embodiment of the data structure of a measurement transaction package, message, or report sent from a second sensor node (e.g., second vehicle) in response to a measurement verification request from an RSU. In one embodiment, when a second node receives the new measurement transaction package the verification phase starts. Any node locating or getting close to the location the unverified measurement was conducted may measure the same modality and compare the result with the transaction. If the measurement is similar or within a required accuracy limit (e.g., error threshold), the verification may continue to check for the LIT. As shown in Table 3, the verification measurement package data structure may comprise any protocol details, the original location of the unverified measurement (e.g., in GPS coordinates), a reference location (e.g., in GPS coordinates), the LIT, and a measurement data field for this sensor node. In some embodiments, additional or fewer fields may be included in a verification transaction message, such as timestamps, etc. Protocol Details, version

Original location (GPS coordinates)

Reference location (GPS coordinates)

Localized identification token (LIT)

This node's measurement data field

Table 3.

[0077] In some embodiments, variations of the disclosed methods and systems may be used. For example, in regards to storing the data, alternatives may be used. Some embodiments use a decentralized sensor network in which the collected data is stored in the blockchain and hence available for all users. In some alternative embodiments, the verified data transactions in a blockchain may contain a link to the actual location of the measurement data. For example, instead of having measurement data, time stamps, location information and reference data fields in each transaction according to Table 3, the transaction may contain the link to the actual database hosting these data fields. In some embodiments, the link may contain an HTTP request with the address and query parameters for easy access.

[0078] In some embodiments, the location that stores the data is the local infrastructure nodes hosting the global blockchain. One potential advantage may be that the actual blockchain maintained by all the infrastructure nodes may be lighter. Additionally, the local data actually collected in the neighborhood or region of the local node may also be stored in the same node.

[0079] In some embodiments, storing the data from a given area physically in local infrastructure nodes may make data recovery more efficient, for example in navigation in traffic. When a navigation client requests data covering a planned route, the actual data may be fetched from the infrastructure nodes along the route, rather than from a central database.

Exemplary Use Cases.

[0080] Autonomous driving is an exemplary field which may benefit from reliable data in the surrounding environment. Each vehicle is constantly collecting vast amounts of sensor data about the traffic, mapping, road condition, weather, topographical details on road slope, etc. A centralized database would require a special service provider with some form of service policies, accounts, and possible service fees for the latest information. The whole system would further be heavily dependent on the functionality and control policy of the central database.

[0081] Decentralized data contributes to the independence of the autonomous traffic. Vehicles may share and validate the data among themselves and build their own enhancements on top of existing mapping data. Drivers themselves may also share findings, for example with navigation services and applications. This data may also be incorporated in decentralized data for similar automatic verification. In some cases, the data collection process may be anonymous while also permitting reliable validation of the data.

[0082] In one example, navigation is based on the mapping information. In addition to driving instructions, directions and optimal route, the mapping may contain topographical information, traffic congestion data, etc. Centralized maps generally cannot be up to date at all times regarding information such as new traffic signs, road works, possible restrictions due to maintenance work or accidents, and the like. However, vehicles in the traffic naturally make observations and may detect any changes or deviations from established data. In addition, in some cases vehicles may measure new information that is absent from the regular mapping information.

[0083] In some embodiments, the decentralized databases may contain data gathered from any type of sensor modalities, ranging from road conditions to revised mapping details and weather information. For autonomous vehicles, relevant information may include road mapping enhancements. Any changes impacting the navigation and second-by-second driving conditions may be useful. Accordingly, data items which a decentralized data management system, as disclosed herein, may be established to manage may, for example, include details about new traffic signs, detours, obstacles on the street(s), changed traffic arrangements, etc. In some embodiments, each of these items may have its own sensor modality code. A vehicle detecting an event, such as a hole in the road detected with a LiDAR sensor, may classify the detail and create a measurement transaction containing a problem classification, location, and detection time. Another vehicle using pattern recognition on video images may detect a new traffic sign that was previously not marked on the map. Later vehicles detecting the same detail problems may then verify the data and provide the verifications to the decentralized system.

[0084] In some embodiments, mapping data can be enhanced by adding new details in the local databases hosted by individual vehicles. For example, a mapping detail such as a negatively banked turn may require special attention from a driver. This type of information is not readily available in conventional road maps downloaded from existing services, but can be added when vehicles collect the data and then share it with other vehicles.

[0085] Each distributed database instance in a local infrastructure node may host its own database. The database may contain details about the traffic conditions and mapping information within the node coverage area (e.g., neighborhood or region). Hence, the global data may be distributed in smaller pieces along the highways and streets.

[0086] When global traffic data is distributed between the local infrastructure nodes, each autonomous vehicle is not required to carry global detailed data in its own databases. Therefore, an autonomous vehicle planning a route to a desired destination may search the local databases along that route and download the relevant data from the local infrastructure nodes along that route.

[0087] Each autonomous vehicle thus stores only the databases that are relevant for its operation. Detailed global data is not needed at all times.

Exemplary Embodiments.

[0088] In one exemplary method, a segment-start roadside unit (RSU) transmits a time- specific, cryptographically generated local identification token (LIT) to a passing vehicle. The vehicle identifies a segment condition (e.g., a traffic level) and/or an anomaly or discrepancy (as compared to its stored mapping data/conditions) and creates a segment record reporting the condition or anomaly. The vehicle transmits the segment record and the LIT to a segment-end RSU when passing by the segment-end RSU. One of the RSUs (or a server, etc.) validates the LIT and updates mapping data based on the segment record.

[0089] In a further exemplary method, a first vehicle approaches a start-marker road side unit (RSU). The first vehicle receives from the start-marker RSU at least a local identification token. Sensors in the first vehicle detect, along a road segment defined between the start-marker RSU and an end-marker RSU, at least one discrepancy as comparted to information stored in a 3-D map of the first vehicle. The first vehicle creates a measurement record of the discrepancy and transmits the measurement record of the discrepancy to a second RSU upon encountering the second RSU.

[0090] In another exemplary method, a start-marker road side unit (RSU) detects a first vehicle. The start-marker RSU communicates a first local identification token (LIT) to the first vehicle. An end-marker RSU subsequently receives from the first vehicle the LIT and at least one measurement record related to at least one discrepancy along a road segment defined between the start-marker RSU and an end-marker RSU. The end-marker RSU identifies the start-marker RSU from information in the LIT and forwards the measurement record to the start-marker RSU. The start-marker RSU validates the LIT information and stores the measurement record as an open measurement transaction in need of validation. Subsequently, in some such embodiments, the start-marker RSU detects at least a second vehicle and communicates to the second vehicle a second LIT and a query related to at least one open measurement transaction. The end-marker RSU receives from the second vehicle the second LIT and a measurement record related to the open measurement transaction. The end-marker RSI identifies the start-marker RSU from the second LIT and forwards to the start-marker RSU the measurement record related to the open measurement transaction. The start-marker RSU validates the LIT information of the measurement record related to the one open measurement transaction and updates the open measurement transaction with the new measurement record. The start-marker RSU further determines whether the open measurement transaction is validated. In some embodiments, determining whether the open measurement transaction is validated is performed by determining whether a preset number of measurements confirm the discrepancy recorded in the open measurement transaction. If the open measurement transaction is validated, the start-marker RSU updates a map database with the information of the measurement transaction. In some embodiments, in response to a third vehicle being detected at the start-marker RSU, the start-marker RSU communicates to the third vehicle at least the updated map information.

[0091] An exemplary system includes at least one processor and non-transitory computer data storage media. The storage media store instructions operative, when executed on the processor, to perform steps comprising (i) receiving at a first vehicle from a start-marker road side unit (RSU) at least a local identification token; (ii) detecting along a road segment defined between the start- marker RSU and an end-marker RSU at least one discrepancy from information stored in a 3-D map of the first vehicle; (iii) creating a measurement record of the at least one discrepancy; and (iv) transmitting the measurement record of the at least one discrepancy from the first vehicle to a second RSU upon encountering the second RSU.

[0092] Another exemplary system includes at least one processor and non-transitory computer data storage media. The media store instructions operative, when executed on the processor, to perform steps comprising: (i) detecting a first vehicle at a start-marker road side unit (RSU); (ii) communicating to the first vehicle from the start-marker RSU at least a first local identification token (LIT); (iii) receiving at a second RSU from the first vehicle at least one measurement record related to at least one discrepancy along a road segment defined between the start-marker RSU and an end-marker RSU; (iv) determining at the second RSU the start-marker RSU from the LIT, and forwarding the at least one measurement record to the start-marker RSU; and (v) validating at the start-marker RSU the LIT information and storing the at least one measurement record as an open measurement transaction in need of validation.

[0093] It should be noted that an RSU may be configured to operate as both a start-marker RSU and an end-marker RSU. For example, a start-marker RSU for vehicles traveling a road segment in one direction may operate as an end-marker RSU for vehicles traveling the same road segment in the opposite direction. Similarly, an end-marker RSU for vehicles traveling in one direction along a road segment may also operate as a start-marker RSU for those same vehicles as they begin traversing the next road segment. It should further be noted that the term "each" as used herein, including in the claims, is not limited to a meaning of "each and every." Exemplary Hardware Architecture.

[0094] Exemplary embodiments disclosed herein are implemented using one or more wired and/or wireless network nodes, such as a wireless transmit/receive unit (WTRU) or other network entity.

[0095] FIG. 6 is a system diagram of an exemplary WTRU 602, which may be employed as a vehicular communication system or road-side unit in embodiments described herein. As shown in FIG. 6, the WTRU 602 may include a processor 618, a communication interface 619 including a transceiver 620, a transmit/receive element 622, a speaker/microphone 624, a keypad 626, a display/touchpad 628, a non-removable memory 630, a removable memory 632, a power source 634, a global positioning system (GPS) chipset 636, and sensors 638. It will be appreciated that the WTRU 602 may include any sub-combination of the foregoing elements while remaining consistent with an embodiment.

[0096] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Array (FPGAs) circuits, any other type of integrated circuit (IC), a state machine, and the like. The processor 1 18 may perform signal coding, data processing, power control, input/output processing, and/or any other functionality that enables the WTRU 602 to operate in a wireless environment. The processor 618 may be coupled to the transceiver 620, which may be coupled to the transmit/receive element 622. While FIG. 6 depicts the processor 618 and the transceiver 620 as separate components, it will be appreciated that the processor 618 and the transceiver 620 may be integrated together in an electronic package or chip.

[0097] The transmit/receive element 622 may be configured to transmit signals to, or receive signals from, a base station over the air interface 616. For example, in one embodiment, the transmit/receive element 622 may be an antenna configured to transmit and/or receive RF signals. In another embodiment, the transmit/receive element 622 may be an emitter/detector configured to transmit and/or receive IR, UV, or visible light signals, as examples. In yet another embodiment, the transmit/receive element 622 may be configured to transmit and receive both RF and light signals. It will be appreciated that the transmit/receive element 622 may be configured to transmit and/or receive any combination of wireless signals.

[0098] In addition, although the transmit/receive element 622 is depicted in FIG. 6 as a single element, the WTRU 602 may include any number of transmit/receive elements 622. More specifically, the WTRU 602 may employ MTMO technology. Thus, in one embodiment, the WTRU 602 may include two or more transmit/receive elements 622 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 616.

[0099] The transceiver 620 may be configured to modulate the signals that are to be transmitted by the transmit/receive element 622 and to demodulate the signals that are received by the transmit/receive element 622. As noted above, the WTRU 602 may have multi-mode capabilities. Thus, the transceiver 620 may include multiple transceivers for enabling the WTRU 602 to communicate via multiple RATs, such as UTRA and IEEE 802.11, as examples.

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

[0101] The processor 618 may receive power from the power source 634, and may be configured to distribute and/or control the power to the other components in the WTRU 602. The power source 634 may be any suitable device for powering the WTRU 602. As examples, the power source 634 may include one or more dry cell batteries (e.g., nickel-cadmium (NiCd), nickel- zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li -ion), and the like), solar cells, fuel cells, and the like.

[0102] The processor 618 may also be coupled to the GPS chipset 636, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 602. In addition to, or in lieu of, the information from the GPS chipset 636, the WTRU 602 may receive location information over the air interface 616 from a base station and/or determine its location based on the timing of the signals being received from two or more nearby base stations. It will be appreciated that the WTRU 602 may acquire location information by way of any suitable location-determination method while remaining consistent with an embodiment. [0103] The processor 618 may further be coupled to other peripherals 638, which may include one or more software and/or hardware modules that provide additional features, functionality and/or wired or wireless connectivity. For example, the peripherals 638 may include sensors such as an accelerometer, an e-compass, a satellite transceiver, a digital camera (for photographs or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, and the like.

[0104] FIG. 7 depicts an exemplary network entity 790 that may be used in embodiments of the present disclosure. As depicted in FIG. 7, network entity 790 includes a communication interface 792, a processor 794, and non-transitory data storage 796, all of which are communicatively linked by a bus, network, or other communication path 798.

[0105] Communication interface 792 may include one or more wired communication interfaces and/or one or more wireless-communication interfaces. With respect to wired communication, communication interface 792 may include one or more interfaces such as Ethernet interfaces, as an example. With respect to wireless communication, communication interface 792 may include components such as one or more antennae, one or more transceivers/chipsets designed and configured for one or more types of wireless (e.g., LTE) communication, and/or any other components deemed suitable by those of skill in the relevant art. And further with respect to wireless communication, communication interface 792 may be equipped at a scale and with a configuration appropriate for acting on the network side— as opposed to the client side— of wireless communications (e.g., LTE communications, Wi-Fi communications, and the like). Thus, communication interface 792 may include the appropriate equipment and circuitry (perhaps including multiple transceivers) for serving multiple mobile stations, UEs, or other access terminals in a coverage area.

[0106] Processor 794 may include one or more processors of any type deemed suitable by those of skill in the relevant art, some examples including a general-purpose microprocessor and a dedicated DSP.

[0107] Data storage 796 may take the form of any non-transitory computer-readable medium or combination of such media, some examples including flash memory, read-only memory (ROM), and random-access memory (RAM) to name but a few, as any one or more types of non- transitory data storage deemed suitable by those of skill in the relevant art could be used. As depicted in FIG. 7, data storage 796 contains program instructions 797 executable by processor 794 for carrying out various combinations of the various network-entity functions described herein. [0108] Although features and elements are described above in particular combinations, one of ordinary skill in the art will appreciate that each feature or element can be used alone or in any combination with the other features and elements. In addition, the methods described herein may be implemented in a computer program, software, or firmware incorporated in a computer- readable medium for execution by a computer or processor. Examples of computer-readable storage media include, but are not limited to, a read only memory (ROM), a random access memory (RAM), a register, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD- ROM disks, and digital versatile disks (DVDs). A processor in association with software may be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.

Claims

CLAIMS We claim:

1. A method comprising:

at an end-marker road-side unit (RSU) positioned at an end of a road segment, receiving a plurality of measurement records from a plurality of respective vehicles that have traversed the road segment, each measurement record including a respective local identification token (LIT); validating at least a subset of the measurement records using the respective local identification tokens;

determining whether at least a threshold number of the validated measurement records report a common discrepancy in a condition of the road segment as compared to map data of the road segment;

in response to a determination that at least the threshold number of validated measurement records report the discrepancy, updating the map data of the road segment consistent with the reported discrepancy.

2. The method of claim 1, further comprising, at a start-marker road-side unit positioned at a start of the road segment, sending respective local identification tokens to the respective vehicles entering the road segment.

3. The method of claim 2, further comprising generating a hash chain, wherein each local identification token sent by the start-marker road-side unit comprises an entry in the hash chain.

4. The method of claim 2, further comprising sending the map data of the road segment from the start-marker road-side unit to the respective vehicles entering the road segment.

5. The method of claim 4, further comprising, after updating of the map data, sending the updated map data of the road segment from the start-marker road-side unit to additional vehicles entering the road segment

6. The method of claim 1, wherein the measurement records received at the end-marker road-side unit include a first measurement record identifying the discrepancy, the method further comprising: reporting the first measurement record to a start-marker road-side unit positioned at a start of the road segment; and

from the start-marker road-side unit, transmitting to each of a plurality of vehicles entering the road segment: (i) a request to confirm the discrepancy and (ii) a respective local identification token.

7. The method of claim 1, wherein validating a measurement record comprises determining that the local identification token of the invention record comprises a valid entry in a hash chain.

8. The method of claim 1, wherein measurement records are validated using a blockchain mechanism.

9. The method of claim 1, wherein the discrepancy is a pothole.

10. The method of claim 1, wherein the discrepancy is an obstacle.

11. The method of claim 1, wherein the discrepancy is a traffic sign.

12. The method of claim 1, wherein the discrepancy is a change in traffic conditions.

13. The method of claim 1, wherein the threshold number is at least two.

14. The method of claim 1, wherein updating the map data comprises updating locally-stored map data of the road segment at a start-marker road-side unit positioned at a start of the road segment.

15. A system comprising at least one processor and non-transitory computer data storage media storing instructions operative, when executed on the processor, to perform steps comprising: at an end-marker road-side unit (RSU) positioned at an end of a road segment, receiving a plurality of measurement records from a plurality of respective vehicles that have traversed the road segment, each measurement record including a respective local identification token (LIT); validating at least a subset of the measurement records using the respective local identification tokens; determining whether at least a threshold number of the validated measurement records report a common discrepancy in a condition of the road segment as compared to map data of the road segment;