WO2017180382A1 - Système et procédé de validation de données dans un réseau de capteurs décentralisé - Google Patents

Système et procédé de validation de données dans un réseau de capteurs décentralisé Download PDF

Info

Publication number
WO2017180382A1
WO2017180382A1 PCT/US2017/026082 US2017026082W WO2017180382A1 WO 2017180382 A1 WO2017180382 A1 WO 2017180382A1 US 2017026082 W US2017026082 W US 2017026082W WO 2017180382 A1 WO2017180382 A1 WO 2017180382A1
Authority
WO
WIPO (PCT)
Prior art keywords
road segment
marker
measurement
road
rsu
Prior art date
Application number
PCT/US2017/026082
Other languages
English (en)
Inventor
Pasi Sakari Ojala
Samian Kaur
Alexander Reznik
Original Assignee
Pcms Holdings, Inc.
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 Pcms Holdings, Inc. filed Critical Pcms Holdings, Inc.
Publication of WO2017180382A1 publication Critical patent/WO2017180382A1/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/38—Electronic maps specially adapted for navigation; Updating thereof
    • G01C21/3804—Creation or updating of map data
    • G01C21/3833—Creation or updating of map data characterised by the source of data
    • G01C21/3841—Data obtained from two or more sources, e.g. probe vehicles
    • 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
    • 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/38—Electronic maps specially adapted for navigation; Updating thereof
    • G01C21/3804—Creation or updating of map data
    • G01C21/3807—Creation or updating of map data characterised by the type of data
    • G01C21/3815—Road data
    • G01C21/3822—Road feature data, e.g. slope data
    • 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/0133—Traffic data processing for classifying traffic situation
    • G—PHYSICS
    • G08—SIGNALLING
    • G08G—TRAFFIC CONTROL SYSTEMS
    • G08G1/00—Traffic control systems for road vehicles
    • G08G1/09—Arrangements for giving variable traffic instructions
    • G08G1/0962—Arrangements for giving variable traffic instructions having an indicator mounted inside the vehicle, e.g. giving voice messages
    • G08G1/0967—Systems involving transmission of highway information, e.g. weather, speed limits
    • G08G1/096766—Systems involving transmission of highway information, e.g. weather, speed limits where the system is characterised by the origin of the information transmission
    • G08G1/096775—Systems involving transmission of highway information, e.g. weather, speed limits where the system is characterised by the origin of the information transmission where the origin of the information is a central station

Definitions

  • 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.
  • CAMP Crash Avoidance Metrics Partnership
  • 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.
  • 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.
  • 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.
  • a start-marker road-side unit 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.
  • a threshold number e.g. at least two
  • 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.
  • the end-marker RSU 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).
  • 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.
  • 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.
  • measurement records are validated using a blockchain mechanism.
  • FIG. 1 is a schematic diagram of one embodiment of a method of data validation in a decentralized sensor network.
  • 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.
  • FIGs. 3 A-3C are a sequence diagram of one embodiment of a method of data validation in a decentralized sensor network.
  • FIG. 4 depicts an exemplary reverse hash chain (RHC).
  • FIG. 5 is a flow block diagram of one embodiment of a method of data validation using a blockchain mechanism.
  • 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.
  • WTRU wireless transmit/receive unit
  • FIG. 7 illustrates an exemplary network entity that may be employed in some embodiments, for example as a map server or road-side unit.
  • modules that carry out (i.e., perform, execute, and the like) various functions that are described herein in connection with the respective modules.
  • 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.
  • ASICs application-specific integrated circuits
  • FPGAs field programmable gate arrays
  • 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.
  • 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.
  • 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.
  • 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).
  • 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).
  • LIT Local Identification Token
  • the message may contain additional pieces of information.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the measurement record may be validated and a map database maintained by mapping server 116 and/or by the RSUs may be updated accordingly.
  • the updated map information may be provided to all vehicles taking the road segment, as needed.
  • the map database may be centrally deployed as a cloud server 116, or distributed and provided for road segments as needed by RSUs.
  • modifications may be performed to reduce the overhead of the message exchange.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the present disclosure relates to a method of using a Local Identification Token (LIT).
  • LIT Local Identification Token
  • 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.
  • 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.
  • 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.
  • Local databases may be established along various highway and street networks.
  • a lamp post may host a peer network node that maintains a distributed database instance for traffic and mapping data of that area.
  • 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.
  • FIG. 2 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).
  • IE infrastructure element
  • 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.
  • the sensor nodes 208a, 208b, 208c perform measurements of the road segment and upload the measurements along with a localized identification token (LIT).
  • LIT localized identification token
  • 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.
  • a vehicle may have downloaded a corresponding database for navigation purposes.
  • the first sensor node may create a measurement transaction.
  • 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.
  • 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.
  • 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
  • Car A 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.
  • a data message such as including an up- to-date map, an LIT, an RSU ID, a timestamp, and the like. In some embodiments, fewer than these elements may be received.
  • Car A's sensors may detect a
  • 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).
  • 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.
  • 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.
  • the stop RSU may forward the transaction to the start RSU (step 318).
  • Car B 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.
  • Car B is able to confirm or validate the open transaction.
  • 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.
  • the stop RSU may forward the transaction(s) to the start RSU (step 332).
  • the open transaction created by Car A may be marked as validated (step 334) in light of the validation report from Car B.
  • Car C 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).
  • the validated information may be used in other ways.
  • the present disclosure relates to a method of using a reverse hash chain to assist in validation of data measurements.
  • 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.
  • 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.
  • a hash function can be applied successively to additional pieces of data in order to record the chronology of the data's existence.
  • FIG. 4 depicts an exemplary embodiment of a reverse hash chain (RHC).
  • RHC reverse hash chain
  • the start-marker RSU may pre-generate the following tokens by repeated hashing of an initial seed Vo, and use Vi as an LIT.
  • 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.
  • 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.
  • the car may be provided with an LIT of VN, or the car may be provided with nothing.
  • 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.
  • 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).
  • FIG. 5 depicts a flow block diagram of one embodiment of a method of data validation using a blockchain mechanism.
  • a vehicle conducting a measurement (step 502) may create an open measurement transaction block and broadcast it to a peer network (step 504).
  • 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).
  • 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.
  • 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).
  • 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.
  • only the nodes within a predetermined distance may handle the operation and accept the new entry in their blockchain 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.
  • 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.
  • the content of messages or reports communicated or passed between vehicles, RSUs, and others may comprise various different details or information.
  • a measurement transaction may comprise a message or report of a sensor measurement.
  • 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.
  • the node e.g., a sensor of a vehicle
  • Table 1 depicts an exemplary embodiment of a measurement transaction data structure, with its various data fields.
  • 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).
  • additional or fewer fields may be included in a transaction message.
  • Timestamp start time of measurement
  • Table 2 depicts an exemplary embodiment of a measurement data field which may be included in the data structure as illustrated in Table 1.
  • the actual data field of the transaction package may contain any sensor modality, continuous signal, or status message.
  • the details in the structure may be coded in a transaction packet as one single row.
  • the number of bytes for each data item may be fixed.
  • the network(s) may generate pools or lists or measurement transaction messages or reports.
  • a node may make a new measurement, issue a new transaction, and upload that transaction to an infrastructure element (e.g., RSU).
  • RSU infrastructure element
  • any other nodes e.g., cars
  • the LIT may be a nonce, or a key generated using the physical channel between the RSU and the sensor node.
  • each transaction may be anonymous.
  • a network node may have information identifying the specific user or application which created the transaction.
  • 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.
  • a second sensor node e.g., second vehicle
  • 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.
  • a required accuracy limit e.g., error threshold
  • 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.
  • additional or fewer fields may be included in a verification transaction message, such as timestamps, etc.
  • LIT Localized identification token
  • variations of the disclosed methods and systems may be used.
  • 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.
  • the verified data transactions in a blockchain may contain a link to the actual location of the measurement data.
  • the transaction 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.
  • the link may contain an HTTP request with the address and query parameters for easy access.
  • 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.
  • storing the data from a given area physically in local infrastructure nodes may make data recovery more efficient, for example in navigation in traffic.
  • 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.
  • 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.
  • 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.
  • mapping is based on the mapping information.
  • 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.
  • vehicles in the traffic naturally make observations and may detect any changes or deviations from established data.
  • vehicles may measure new information that is absent from the regular mapping information.
  • the decentralized databases may contain data gathered from any type of sensor modalities, ranging from road conditions to revised mapping details and weather information.
  • relevant information may include road mapping enhancements. Any changes impacting the navigation and second-by-second driving conditions may be useful.
  • 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.
  • 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.
  • 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.
  • 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.
  • each autonomous vehicle 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.
  • Each autonomous vehicle thus stores only the databases that are relevant for its operation. Detailed global data is not needed at all times.
  • a segment-start roadside unit 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.
  • 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.
  • a start-marker road side unit 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.
  • 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.
  • 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.
  • 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.
  • RSU start-marker road side unit
  • 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.
  • RSU start-marker road side unit
  • LIT local identification token
  • an RSU may be configured to operate as both a start-marker RSU and an end-marker RSU.
  • 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.
  • 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.
  • ach as used herein, including in the claims, is not limited to a meaning of "each and every.” Exemplary Hardware Architecture.
  • 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.
  • WTRU wireless transmit/receive unit
  • 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.
  • 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.
  • GPS global positioning system
  • 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.
  • the transmit/receive element 622 may be configured to transmit signals to, or receive signals from, a base station over the air interface 616.
  • the transmit/receive element 622 may be an antenna configured to transmit and/or receive RF signals.
  • the transmit/receive element 622 may be an emitter/detector configured to transmit and/or receive IR, UV, or visible light signals, as examples.
  • 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.
  • 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.
  • 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.
  • 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.
  • the WTRU 602 may have multi-mode capabilities.
  • 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.
  • 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.
  • 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.
  • SIM subscriber identity module
  • SD secure digital
  • 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).
  • 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.
  • 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.
  • 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.
  • location information e.g., longitude and latitude
  • 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.
  • 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.
  • 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.
  • 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
  • FIG. 7 depicts an exemplary network entity 790 that may be used in embodiments of the present disclosure.
  • 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.
  • 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.
  • wireless communication interface 792 may include the appropriate equipment and circuitry (perhaps including multiple transceivers)
  • 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.
  • 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.
  • ROM read only memory
  • RAM random access memory
  • 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.

Abstract

L'invention concerne des systèmes et des procédés associés à la validation de données dans des réseaux de capteurs décentralisés. Des exemples de modes de réalisation utilisent des jetons d'identification locaux (LIT) conjointement avec le stockage de données dans une infrastructure locale en tant qu'instances locales d'une base de données. Un réseau homologue peut comprendre des nœuds de capteur et des données de gestion d'infrastructure locale se rapportant à une zone locale. Un véhicule peut se connecter au nœud d'infrastructure le plus proche dans un réseau homologue. Le véhicule télécharge la base de données correspondante pour la navigation. Un capteur de véhicule détecte un nouvel événement tel qu'un nouveau panneau de signalisation et crée une transaction de mesure. Un autre véhicule qui pénètre dans le segment de route peut se connecter au nœud d'infrastructure local et recevoir la nouvelle transaction ouverte ainsi que le jeton d'identification local associé. Les données provenant des capteurs du deuxième véhicule sont téléversées. Le LIT du nœud de capteur est fourni à un équipement d'infrastructure en aval qui, à son tour, valide le LIT et corrèle les mesures afin de déterminer si le rapport de mesure est validé.
PCT/US2017/026082 2016-04-12 2017-04-05 Système et procédé de validation de données dans un réseau de capteurs décentralisé WO2017180382A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201662321462P 2016-04-12 2016-04-12
US62/321,462 2016-04-12

Publications (1)

Publication Number Publication Date
WO2017180382A1 true WO2017180382A1 (fr) 2017-10-19

Family

ID=58645378

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2017/026082 WO2017180382A1 (fr) 2016-04-12 2017-04-05 Système et procédé de validation de données dans un réseau de capteurs décentralisé

Country Status (1)

Country Link
WO (1) WO2017180382A1 (fr)

Cited By (49)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108154704A (zh) * 2017-12-27 2018-06-12 武汉邮电科学研究院 基于区块链的智慧停车系统及方法
CN108959563A (zh) * 2018-07-04 2018-12-07 东北大学 一种容量可扩展区块链查询方法及系统
WO2018230581A1 (fr) * 2017-06-12 2018-12-20 Panasonic Intellectual Property Management Co., Ltd. Système et procédé d'authentification dynamique de données cartographiques à l'aide de chaînes de blocs
CN109255856A (zh) * 2018-08-20 2019-01-22 深圳市长龙铁路电子工程有限公司 一种基于区块链技术的机车信号设备数据记录方法
CN109360417A (zh) * 2018-10-19 2019-02-19 福建工程学院 一种基于区块链的危险驾驶行为辨识与推送方法及系统
CN109377748A (zh) * 2018-12-03 2019-02-22 武汉理工大学 一种基于区块链的乘客出行数据采集存储系统及方法
DE102017221477A1 (de) * 2017-11-29 2019-05-29 Hochschule für Angewandte Wissenschaften Hamburg Sensorknoten und gesichertes Sensornetzwerk
DE102018201417A1 (de) 2018-01-30 2019-08-01 Volkswagen Aktiengesellschaft Verfahren zum Bereitstellen verifizierter Informationen über ein Verkehrszeichen, Verkehrszeichenanlage sowie Verfahren für ein Navigationssystem zur Verifikation eines Verkehrszeichens
WO2019152049A1 (fr) * 2018-02-02 2019-08-08 Ford Global Technologies, Llc Identification de divergence de carte avec des données de carte centralisées
WO2019156916A1 (fr) * 2018-02-07 2019-08-15 3M Innovative Properties Company Validation de fonctionnement de véhicule à l'aide d'articles de trajectoire et de chaîne de blocs
CN110182152A (zh) * 2018-02-22 2019-08-30 通用汽车有限责任公司 用于减轻互联车辆系统中的异常数据的系统和方法
CN110187701A (zh) * 2018-02-22 2019-08-30 通用汽车有限责任公司 在车联网中用分布式总账管理信任的系统和方法
EP3528457A3 (fr) * 2018-02-19 2019-10-23 Deutsche Telekom AG Détection collaborative d'anomalies de l'internet des objets
WO2019072311A3 (fr) * 2018-12-29 2019-10-24 Alibaba Group Holding Limited Production participative basée sur une chaîne de blocs d'applications cartographiques
EP3576031A1 (fr) * 2018-05-30 2019-12-04 Robert Bosch GmbH Procédé et dispositif de vérification de l'état de choses dans un système de transaction décentralisé
US10535271B1 (en) 2018-10-10 2020-01-14 Waymo Llc Smart signs for autonomous vehicles
EP3545665A4 (fr) * 2018-12-29 2020-01-22 Alibaba Group Holding Limited Système et procédé de détection d'attaque par réinsertion
EP3574461A4 (fr) * 2018-12-29 2020-01-22 Alibaba Group Holding Limited Système et procédé de détection d'une attaque par rejeu
EP3609123A1 (fr) * 2018-08-08 2020-02-12 Robert Bosch GmbH Procédé et dispositif de vérification de la situation actuelle dans un système de transaction décentralisé
CN110795439A (zh) * 2018-08-02 2020-02-14 辉达公司 使用区块链平台使能地图更新的方法和设备
US20200128044A1 (en) * 2018-12-29 2020-04-23 Alibaba Group Holding Limited System and method for detecting replay attack
CN111064800A (zh) * 2019-12-26 2020-04-24 杭州云象网络技术有限公司 一种基于区块链技术的安全车联社交网络建设方法
US10681083B2 (en) 2018-12-29 2020-06-09 Alibaba Group Holding Limited System and method for detecting replay attack
CN111461468A (zh) * 2019-01-02 2020-07-28 中国移动通信有限公司研究院 数据处理方法及装置、数据节点及存储介质
USD894020S1 (en) 2018-12-13 2020-08-25 Waymo Llc Three-dimensional sign
EP3736789A1 (fr) * 2019-05-09 2020-11-11 Volkswagen Ag Procédé et système de fourniture des informations d'environnement
WO2020244787A1 (fr) * 2019-06-07 2020-12-10 NEC Laboratories Europe GmbH Procédé et système d'identification et de diffusion d'événements dynamiques
US10878701B2 (en) 2018-10-09 2020-12-29 Ford Global Technologies, Llc Detection of attacks on vehicle networks
CN112188433A (zh) * 2020-09-14 2021-01-05 北京梧桐车联科技有限责任公司 信息处理方法及装置、路侧设备、v2x的通信系统及介质
FR3100203A1 (fr) * 2019-08-27 2021-03-05 Psa Automobiles Sa Procédé et dispositif d’alerte d’évènement pour véhicule
US20210097854A1 (en) * 2020-12-14 2021-04-01 Intel Corporation Monitoring system, apparatus of a vehicle, apparatus of a roadside unit, traffic infrastructure system, and methods thereof
CN112729316A (zh) * 2019-10-14 2021-04-30 北京图森智途科技有限公司 自动驾驶车辆的定位方法、装置、车载设备、系统及车辆
EP3819888A1 (fr) * 2019-11-05 2021-05-12 Valeo Comfort and Driving Assistance Système pour un véhicule permettant de détecter et de valider un événement à l'aide d'un modèle d'apprentissage profond
WO2021122087A1 (fr) * 2019-12-20 2021-06-24 Robert Bosch Gmbh Procédé et dispositif de détection de données de circulation
US11055412B2 (en) 2018-12-20 2021-07-06 At&T Intellectual Property I, L.P. Method and system for stake-based event management with ledgers
CN113347000A (zh) * 2021-06-09 2021-09-03 哈尔滨工程大学 一种面向共谋攻击的真实路况数据聚合方法
US11245749B2 (en) 2017-11-13 2022-02-08 Toyota Jidosha Kabushiki Kaisha Vehicle information communication system and environment improvement system, and server used therein
USD958245S1 (en) 2018-10-10 2022-07-19 Waymo Llc Three-dimensional sign
US20220234613A1 (en) * 2021-01-26 2022-07-28 Honda Research Institute Europe Gmbh Method, system and vehicle for assisting an operator of the vehicle in assessing a traffic situation with shared traffic space
US11408750B2 (en) 2020-06-29 2022-08-09 Toyota Research Institute, Inc. Prioritizing collecting of information for a map
USD960722S1 (en) 2018-12-13 2022-08-16 Waymo Llc Three-dimensional sign
US11423405B2 (en) 2019-09-10 2022-08-23 International Business Machines Corporation Peer validation for unauthorized transactions
US11431477B2 (en) 2018-05-14 2022-08-30 nChain Holdings Limited Computer-implemented systems and methods for using a blockchain to perform an atomic swap
US11558195B2 (en) * 2020-02-06 2023-01-17 Ford Global Technologies, Llc Proof-of-work vehicle message authentication
EP4035049A4 (fr) * 2019-09-27 2023-06-28 INTEL Corporation Services de cartes sécurisées hd utilisant une chaîne de blocs
US11709819B2 (en) 2020-09-30 2023-07-25 International Business Machines Corporation Validating test results using a blockchain network
US11741239B2 (en) 2018-10-17 2023-08-29 Omnitracs, Llc Blockchain-based hours-of-service system
WO2023217569A1 (fr) 2022-05-10 2023-11-16 Mercedes-Benz Group AG Procédé d'enregistrement incrémentiel d'une carte routière selon un protocole de consensus
US11915308B2 (en) 2018-05-10 2024-02-27 Miovision Technologies Incorporated Blockchain data exchange network and methods and systems for submitting data to and transacting data on such a network

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040230373A1 (en) * 2003-05-12 2004-11-18 Assimakis Tzamaloukas Hierarchical floating car data network
WO2008063899A2 (fr) * 2006-11-10 2008-05-29 Toyota Motor Engineering & Manufacturing North America, Inc. Procédé pour échanger un message et vérifier l'authenticité des messages dans un réseau ad hoc
WO2010105712A1 (fr) * 2009-03-16 2010-09-23 Tele Atlas B.V. Système et procédé pour vérifier des rapports de mise à jour de carte à l'aide de données de sonde
US20130033384A1 (en) * 2009-11-25 2013-02-07 Coyote System Sas Customized system for vehicle driving assistance
US20150185036A1 (en) * 2012-08-24 2015-07-02 Robert Bosch Gmbh Method and device for ascertaining a source of danger on atravel route

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040230373A1 (en) * 2003-05-12 2004-11-18 Assimakis Tzamaloukas Hierarchical floating car data network
WO2008063899A2 (fr) * 2006-11-10 2008-05-29 Toyota Motor Engineering & Manufacturing North America, Inc. Procédé pour échanger un message et vérifier l'authenticité des messages dans un réseau ad hoc
WO2010105712A1 (fr) * 2009-03-16 2010-09-23 Tele Atlas B.V. Système et procédé pour vérifier des rapports de mise à jour de carte à l'aide de données de sonde
US20130033384A1 (en) * 2009-11-25 2013-02-07 Coyote System Sas Customized system for vehicle driving assistance
US20150185036A1 (en) * 2012-08-24 2015-07-02 Robert Bosch Gmbh Method and device for ascertaining a source of danger on atravel route

Cited By (78)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10663303B2 (en) 2017-06-12 2020-05-26 Panasonic Intellectual Property Management Co., Ltd. System and method for dynamically authenticating map data using blockchains
JP7054778B2 (ja) 2017-06-12 2022-04-15 パナソニックＩｐマネジメント株式会社 ブロックチェーンを使用してマップデータを動的に認証するシステムおよび方法
WO2018230581A1 (fr) * 2017-06-12 2018-12-20 Panasonic Intellectual Property Management Co., Ltd. Système et procédé d'authentification dynamique de données cartographiques à l'aide de chaînes de blocs
JP2020523579A (ja) * 2017-06-12 2020-08-06 パナソニックＩｐマネジメント株式会社 ブロックチェーンを使用してマップデータを動的に認証するシステムおよび方法
US11245749B2 (en) 2017-11-13 2022-02-08 Toyota Jidosha Kabushiki Kaisha Vehicle information communication system and environment improvement system, and server used therein
DE102017221477A1 (de) * 2017-11-29 2019-05-29 Hochschule für Angewandte Wissenschaften Hamburg Sensorknoten und gesichertes Sensornetzwerk
WO2019105730A1 (fr) * 2017-11-29 2019-06-06 Hochschule für Angewandte Wissenschaften Hamburg Nœuds de capteur et réseau de capteur sécurisé
CN108154704B (zh) * 2017-12-27 2020-07-07 武汉邮电科学研究院 基于区块链的智慧停车系统及方法
CN108154704A (zh) * 2017-12-27 2018-06-12 武汉邮电科学研究院 基于区块链的智慧停车系统及方法
DE102018201417A1 (de) 2018-01-30 2019-08-01 Volkswagen Aktiengesellschaft Verfahren zum Bereitstellen verifizierter Informationen über ein Verkehrszeichen, Verkehrszeichenanlage sowie Verfahren für ein Navigationssystem zur Verifikation eines Verkehrszeichens
EP3518207A3 (fr) * 2018-01-30 2019-08-07 Volkswagen Aktiengesellschaft Procédé de fourniture des informations vérifiées sur un panneau de signalisation routière, installation de panneaux de signalisation routière ainsi que procédé pour un système de navigation permettant de vérifier un panneau de signalisation routière
WO2019152049A1 (fr) * 2018-02-02 2019-08-08 Ford Global Technologies, Llc Identification de divergence de carte avec des données de carte centralisées
WO2019156916A1 (fr) * 2018-02-07 2019-08-15 3M Innovative Properties Company Validation de fonctionnement de véhicule à l'aide d'articles de trajectoire et de chaîne de blocs
EP3528457A3 (fr) * 2018-02-19 2019-10-23 Deutsche Telekom AG Détection collaborative d'anomalies de l'internet des objets
US10599140B2 (en) 2018-02-22 2020-03-24 General Motors Llc System and method for mitigation of anomalous data in a connected vehicle system
CN110182152B (zh) * 2018-02-22 2022-11-08 通用汽车有限责任公司 用于减轻互联车辆系统中的异常数据的系统和方法
CN110182152A (zh) * 2018-02-22 2019-08-30 通用汽车有限责任公司 用于减轻互联车辆系统中的异常数据的系统和方法
CN110187701A (zh) * 2018-02-22 2019-08-30 通用汽车有限责任公司 在车联网中用分布式总账管理信任的系统和方法
US11915308B2 (en) 2018-05-10 2024-02-27 Miovision Technologies Incorporated Blockchain data exchange network and methods and systems for submitting data to and transacting data on such a network
US11431477B2 (en) 2018-05-14 2022-08-30 nChain Holdings Limited Computer-implemented systems and methods for using a blockchain to perform an atomic swap
US11764947B2 (en) 2018-05-14 2023-09-19 Nchain Licensing Ag Systems and methods for storage, generation and verification of tokens used to control access to a resource
US11917051B2 (en) 2018-05-14 2024-02-27 Nchain Licensing Ag Systems and methods for storage, generation and verification of tokens used to control access to a resource
US11838407B2 (en) 2018-05-14 2023-12-05 Nchain Licensing Ag Computer-implemented systems and methods for using a blockchain to perform an atomic swap
EP3576031A1 (fr) * 2018-05-30 2019-12-04 Robert Bosch GmbH Procédé et dispositif de vérification de l'état de choses dans un système de transaction décentralisé
CN108959563A (zh) * 2018-07-04 2018-12-07 东北大学 一种容量可扩展区块链查询方法及系统
US11703348B2 (en) 2018-08-02 2023-07-18 Nvidia Corporation Method and apparatus for enabling map updates using a blockchain platform
US10915115B2 (en) 2018-08-02 2021-02-09 Nvidia Corporation Method and apparatus for enabling map updates using a blockchain platform
CN110795439A (zh) * 2018-08-02 2020-02-14 辉达公司 使用区块链平台使能地图更新的方法和设备
EP3609123A1 (fr) * 2018-08-08 2020-02-12 Robert Bosch GmbH Procédé et dispositif de vérification de la situation actuelle dans un système de transaction décentralisé
US11269862B2 (en) 2018-08-08 2022-03-08 Robert Bosch Gmbh Method and device for checking a situation in a decentralized transaction system
CN109255856A (zh) * 2018-08-20 2019-01-22 深圳市长龙铁路电子工程有限公司 一种基于区块链技术的机车信号设备数据记录方法
US10878701B2 (en) 2018-10-09 2020-12-29 Ford Global Technologies, Llc Detection of attacks on vehicle networks
US10854085B2 (en) 2018-10-10 2020-12-01 Waymo Llc Smart signs for autonomous vehicles
US11443634B2 (en) 2018-10-10 2022-09-13 Waymo Llc Smart signs for autonomous vehicles
USD958245S1 (en) 2018-10-10 2022-07-19 Waymo Llc Three-dimensional sign
US10535271B1 (en) 2018-10-10 2020-01-14 Waymo Llc Smart signs for autonomous vehicles
USD995631S1 (en) 2018-10-10 2023-08-15 Waymo Llc Three-dimensional sign
USD958244S1 (en) 2018-10-10 2022-07-19 Waymo Llc Three-dimensional sign
US11741239B2 (en) 2018-10-17 2023-08-29 Omnitracs, Llc Blockchain-based hours-of-service system
CN109360417B (zh) * 2018-10-19 2020-03-27 福建工程学院 一种基于区块链的危险驾驶行为辨识与推送方法及系统
CN109360417A (zh) * 2018-10-19 2019-02-19 福建工程学院 一种基于区块链的危险驾驶行为辨识与推送方法及系统
CN109377748A (zh) * 2018-12-03 2019-02-22 武汉理工大学 一种基于区块链的乘客出行数据采集存储系统及方法
USD958243S1 (en) 2018-12-13 2022-07-19 Waymo Llc Three-dimensional sign
USD960722S1 (en) 2018-12-13 2022-08-16 Waymo Llc Three-dimensional sign
USD894020S1 (en) 2018-12-13 2020-08-25 Waymo Llc Three-dimensional sign
US11055412B2 (en) 2018-12-20 2021-07-06 At&T Intellectual Property I, L.P. Method and system for stake-based event management with ledgers
EP3545665A4 (fr) * 2018-12-29 2020-01-22 Alibaba Group Holding Limited Système et procédé de détection d'attaque par réinsertion
US10735464B2 (en) 2018-12-29 2020-08-04 Alibaba Group Holding Limited System and method for detecting replay attack
WO2019072311A3 (fr) * 2018-12-29 2019-10-24 Alibaba Group Holding Limited Production participative basée sur une chaîne de blocs d'applications cartographiques
US11283634B2 (en) 2018-12-29 2022-03-22 Advanced New Technologies Co., Ltd. System and method for detecting replay attack
EP3574461A4 (fr) * 2018-12-29 2020-01-22 Alibaba Group Holding Limited Système et procédé de détection d'une attaque par rejeu
US11323475B2 (en) 2018-12-29 2022-05-03 Advanced New Technologies Co., Ltd. System and method for detecting replay attack
US20200128044A1 (en) * 2018-12-29 2020-04-23 Alibaba Group Holding Limited System and method for detecting replay attack
US10681083B2 (en) 2018-12-29 2020-06-09 Alibaba Group Holding Limited System and method for detecting replay attack
US10677607B2 (en) 2018-12-29 2020-06-09 Alibaba Group Holding Limited Blockchain-based crowdsourcing of map applications
CN111461468B (zh) * 2019-01-02 2023-10-31 中国移动通信有限公司研究院 数据处理方法及装置、数据节点及存储介质
CN111461468A (zh) * 2019-01-02 2020-07-28 中国移动通信有限公司研究院 数据处理方法及装置、数据节点及存储介质
EP3736789A1 (fr) * 2019-05-09 2020-11-11 Volkswagen Ag Procédé et système de fourniture des informations d'environnement
WO2020244787A1 (fr) * 2019-06-07 2020-12-10 NEC Laboratories Europe GmbH Procédé et système d'identification et de diffusion d'événements dynamiques
JP7389144B2 (ja) 2019-06-07 2023-11-29 エヌイーシー ラボラトリーズ ヨーロッパ ゲーエムベーハー 動的なイベントの特定および流布のための方法およびシステム
FR3100203A1 (fr) * 2019-08-27 2021-03-05 Psa Automobiles Sa Procédé et dispositif d’alerte d’évènement pour véhicule
US11423405B2 (en) 2019-09-10 2022-08-23 International Business Machines Corporation Peer validation for unauthorized transactions
EP4035049A4 (fr) * 2019-09-27 2023-06-28 INTEL Corporation Services de cartes sécurisées hd utilisant une chaîne de blocs
CN112729316A (zh) * 2019-10-14 2021-04-30 北京图森智途科技有限公司 自动驾驶车辆的定位方法、装置、车载设备、系统及车辆
EP3819888A1 (fr) * 2019-11-05 2021-05-12 Valeo Comfort and Driving Assistance Système pour un véhicule permettant de détecter et de valider un événement à l'aide d'un modèle d'apprentissage profond
WO2021122087A1 (fr) * 2019-12-20 2021-06-24 Robert Bosch Gmbh Procédé et dispositif de détection de données de circulation
CN111064800A (zh) * 2019-12-26 2020-04-24 杭州云象网络技术有限公司 一种基于区块链技术的安全车联社交网络建设方法
US11558195B2 (en) * 2020-02-06 2023-01-17 Ford Global Technologies, Llc Proof-of-work vehicle message authentication
US11841239B2 (en) 2020-06-29 2023-12-12 Toyota Jidosha Kabushiki Kaisha Prioritizing collecting of information for a map
US11408750B2 (en) 2020-06-29 2022-08-09 Toyota Research Institute, Inc. Prioritizing collecting of information for a map
CN112188433A (zh) * 2020-09-14 2021-01-05 北京梧桐车联科技有限责任公司 信息处理方法及装置、路侧设备、v2x的通信系统及介质
US11709819B2 (en) 2020-09-30 2023-07-25 International Business Machines Corporation Validating test results using a blockchain network
US20210097854A1 (en) * 2020-12-14 2021-04-01 Intel Corporation Monitoring system, apparatus of a vehicle, apparatus of a roadside unit, traffic infrastructure system, and methods thereof
EP4012679A1 (fr) * 2020-12-14 2022-06-15 Intel Corporation Système de surveillance, appareil d'un véhicule, appareil d'unité de bord de route, système d'infrastructure de trafic et procédés associés
US20220234613A1 (en) * 2021-01-26 2022-07-28 Honda Research Institute Europe Gmbh Method, system and vehicle for assisting an operator of the vehicle in assessing a traffic situation with shared traffic space
US11679782B2 (en) * 2021-01-26 2023-06-20 Honda Research Institute Europe Gmbh Method, system and vehicle for assisting an operator of the vehicle in assessing a traffic situation with shared traffic space
CN113347000A (zh) * 2021-06-09 2021-09-03 哈尔滨工程大学 一种面向共谋攻击的真实路况数据聚合方法
WO2023217569A1 (fr) 2022-05-10 2023-11-16 Mercedes-Benz Group AG Procédé d'enregistrement incrémentiel d'une carte routière selon un protocole de consensus

Similar Documents

Publication Publication Date Title
WO2017180382A1 (fr) Système et procédé de validation de données dans un réseau de capteurs décentralisé
US11520331B2 (en) Methods and apparatus to update autonomous vehicle perspectives
US10276039B2 (en) Information sharing among mobile apparatus
CN110361025B (zh) 分层路线生成、提供和选择
Hull et al. Cartel: a distributed mobile sensor computing system
US8954205B2 (en) System and method for road side equipment of interest selection for active safety applications
US11782692B2 (en) Transport component acceptance
KR102549270B1 (ko) 차량용 프로세서의 안전한 부트
Dietzel et al. In-network aggregation for vehicular ad hoc networks
US20180113880A1 (en) Method and apparatus for hierarchical clustering of geographical data
CN109660538B (zh) 基于区块链的车辆通信方法及装置
CN102265118A (zh) 一种基于gps导航系统并结合动态交通数据的路径优化的方法和系统
US11785463B2 (en) Device provisioning and authentication
US20200363211A1 (en) Location correction utilizing vehicle communication networks
KR102227561B1 (ko) 블록체인 기반의 경로 안내 및 교통흐름제어 시스템 및 방법
JP6997557B2 (ja) バレーパーキングシステム、プログラム
JP2014052377A (ja) 交通量の変化を感知して経路を探索する通信型ナビゲーションシステム
Pei et al. Secure and privacy-preserving 3D vehicle positioning schemes for vehicular ad hoc network
US20190158297A1 (en) Communication system and in-vehicle communication apparatus
US20240096211A1 (en) Processing apparatus and method for generating route navigation data
US11438158B2 (en) Provisioning of external functionality to transports
Malik et al. Asymmetric encryption based secure and efficient data gathering technique in VANET
US20220335123A1 (en) Transport component tamper detection
JP7462775B2 (ja) データ処理方法および装置、車両側デバイス、クラウドサーバ、ならびに電子デバイス
WO2022142632A1 (fr) Procédé et système de communication de messages entre des véhicules

Legal Events

Date Code Title Description
DPE1 Request for preliminary examination filed after expiration of 19th month from priority date (pct application filed from 20040101)
NENP Non-entry into the national phase

Ref country code: DE

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

Ref document number: 17720617

Country of ref document: EP

Kind code of ref document: A1

122 Ep: pct application non-entry in european phase

Ref document number: 17720617

Country of ref document: EP

Kind code of ref document: A1