ELECTRONIC DEVICES, SYSTEMS AND METHODS FOR VEHICULAR COMMUNICATION

TECHNICAL FIELD

The present disclosure generally pertains to the field of vehicular communication, in particular to an electronic device, a system and a method for vehicular communication.

TECHNICAL BACKGROUND

Vehicular communication (also called car-to-car communication or vehicle-to-vehicle communication) relates to networks in which vehicles and roadside units are the communicating nodes, providing each other with information, such as safety warnings and traffic information. They can be effective in avoiding accidents and traffic congestion.

Vehicular Ad Hoc Networks (VANETs) are created by applying the principles of Mobile Ad Hoc Networks (MANETs)—the spontaneous creation of a wireless network for data exchange—to the domain of vehicles. Vehicular Ad Hoc Networks are a key component of intelligent transportation systems (ITS).

In Intelligent Vehicular Ad Hoc Networks (InVANET) or intelligent transportation systems (ITS), vehicles are enabled to communicate among themselves (vehicle-to-vehicle, V2V) and via roadside access points (vehicle-to-roadside, V2R) also called Road Side Units (RSUs).

Vehicular communication can contribute to safer and more efficient roads by providing timely information to drivers, and also to make travel more convenient. Vehicular communication also contributes to autonomous and semi-autonomous vehicles.

Although there exist techniques for vehicle communication, it is generally desirable to provide more developed techniques for vehicle communication.

SUMMARY

According to a first aspect the disclosure provides an electronic device that is configured as a host of a distributed ledger, the permission to access the distributed ledger being location based.

According to a further aspect the disclosure provides a system comprising nodes that are configured as hosts of a distributed ledger, the permission to access the distributed ledger being location based.

According to a further aspect the disclosure provides a method of providing a distributed ledger, the permission to access the distributed ledger being location based.

Further aspects are set forth in the dependent claims, the following description and the drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments are explained by way of example with respect to the accompanying drawings, in which:

FIG. 1 describes an exemplifying situation in which two autonomous vehicles interact with each other and with a road side unit via vehicular communication to find consensus concerning their next actions;

FIG. 2 describes an exemplifying situation in which two autonomous vehicles interact with each other via vehicular communication to find consensus concerning their next actions;

FIG. 3 describes a further exemplifying situation in which an autonomous vehicle interacts with a road side unit via vehicular communication to find consensus concerning the vehicle's next actions;

FIG. 4 shows an example of two road side units that are communicatively coupled to close vehicles and a central server;

FIG. 5 shows an example of Vehicle Ad Hoc Peer-to-Peer Networks;

FIG. 6 schematically describes an example wherein, in a merging area of a road vehicles in a certain area get a rule on a smart contract and make a consensus of their behavior in a second area;

FIG. 7 schematically describes a method of providing a location based distributed ledger in the exemplifying scenario of FIG. 6;

FIG. 8 schematically describes an alternative method of providing a location based distributed ledger in the exemplifying scenario of FIG. 6;

FIG. 9 schematically describes an embodiment of an electronic device that may be used in context of the embodiments; and

FIG. 10 schematically describes a further use case in which the vehicles are delivery drones.

DETAILED DESCRIPTION OF EMBODIMENTS

The embodiments disclose an electronic device that is configured as a host of a distributed ledger, the permission to access the distributed ledger being location based. A distributed ledger is a type of database that is spread across multiple sites. According to some embodiments, records are stored one after the other in a distributed ledger when the participants of the ledger reach consensus. A distributed ledger may for example store vehicular data, or the like. A distributed ledger may be used to allow for distributed transaction processing.

The electronic device may for example be a node of a network that hosts a distributed ledger. A node of the distributed ledger may store a full copy of the database, or it may store only parts of the database.

The electronic device may for example be integrated within a vehicle. The electronic device may for example be a processing unit that controls an autonomous driving system of a vehicle. Alternatively, the electronic device may be integrated in a road side unit. A road side unit may be located at the side of a road and control a defined section of the road, or it may be located near a crossing, or the like. In particular, the electronic device may be a server that is located, together with other servers, along a road.

The distributed ledger may be a shared ledger. A shared ledger refers to any database and application that is shared by a group of participants, or that is open to the public. A shared ledger may use a distributed ledger as its underlying database.

The electronic device may for example be a node of a Vehicular Ad Hoc Network. A Vehicular Ad Hoc Network can use any wireless networking technology as its basis. The most prominent are short range radio technologies like WLAN (either standard Wi-Fi or the vehicle-specific IEEE 802.11p), Bluetooth, Visible Light Communication (VLC), Infrared, and ZigBee. In addition, cellular technologies like UMTS, LTE, or WiMAX IEEE 802.16 can support VANETs, forming heterogeneous vehicular networks.

Permission to access the distributed ledger may depend on location. For example, the permission to access the distributed ledger may depend on physical closeness. For example, a vehicle group can be defined as a group of vehicles that are within a certain distance. Such a group of vehicles that are within a certain distance may establish a location based distributed ledger.

Alternatively, a vehicle may also be assigned to a group based on its distance to a road side unit. For instance, a vehicle may be assigned to group A if its closest road side unit is road side unit A.

Physical closeness may be verified by each of the current members of a distributed ledger. For example, the devices at a location may verify each other's physical closeness by means of radio communication, cameras (CCD, TOF etc.), and the like.

The electronic device may further be arranged to contribute to different ledgers as it moves from one location to another. A location based distributed ledger may thus rely not only on an absolute location, e.g. a location with reference to the fixed location of a road side unit, but it may also rely on relative position. In general, a location based distributed ledger may be considered as an independent group, i.e. the ledger is bound to a location or area. However, the users and devices move and are contributing to different ledgers as they move from one location to another.

Vehicles may disconnect and later connect again and then copy the ledger content.

According to some embodiments, the distributed ledger is designed as a block chain. A block chain is a type of database that takes a number of records and puts them in a block. Each block is then linked to the next block, using, e.g. a cryptographic signature. This allows block chains to be used like a ledger, which can be shared and corroborated by anyone with the appropriate permissions. A distributed ledger that is designed as a block chain may thus enable a distributed way to store location dependent vehicular data while having the advantages of a block chain (e.g. irreversibility).

The distributed ledger may be open to the public or may layer on permissions for different types of users. For example, police cars and ambulance cars may have higher permissions than private cars.

The distributed ledger may be a private permissioned ledger for a location. Permissioned ledgers may have one or many owners. When a new record is added, the ledger's integrity may be checked by a limited consensus process. This may be carried out by trusted actors—government departments, for example traffic authorities, police or the like. A permissioned block chain may provide highly-verifiable data sets because the consensus process creates a digital signature, which can be seen by all parties.

A distributed ledger may store vehicular communication data, in particular consensus information related to actions and behavior of vehicles. For example, a group of vehicles achieves consensus on their actions on the road. For this purpose, consensus may be achieved on the actions to be taken.

There are many ways to corroborate the accuracy of a ledger, but they are broadly known as consensus (the term ‘mining’ is used for a variant of this process in the cryptocurrency Bitcoin). The embodiments may use any of the known consensus techniques, for example a mining process. The length of longest chain may determine the ledger state. Still further, a Practical Byzantine Fault tolerance consensus protocol may be used as consensus mechanism.

According to some embodiments, the vehicles receive a smart contract that defines a basic rule for their behavior and they make a consensus of actual behaviors based on the basic rule by communicating with other vehicles in the area.

The vehicular communication data stored by the distributed ledger may comprise a smart contract between a group of vehicles. Smart contracts are contracts whose terms are recorded in a computer language instead of legal language. According to embodiments, smart contracts can be automatically executed by a computing system. By means of a location based distributed ledger, the electronic device may for example provide a behavioral rule distribution for automated vehicles with smart contracts stored in the distributed ledger which is accessible in a certain distance. Consensus may be recorded into a joint smart contract between the group of vehicles. For example, in a merging area of a road, the vehicles in a certain area may get a rule on smart contract and make a consensus of their behavior in the area.

Still further, using a smart contract, an ambulance vehicle may broadcast a rule to surrounding vehicles.

The distributed ledger may record geographical information, previous consensus results, and/or feedback on the execution of a smart contract. Such feedback may be used to assign priorities for future actions taken by vehicles. For instance, when a vehicle has not been able to execute the actions in the smart contract, the vehicle may be given a lower priority for future actions. Another option is that the vehicle owner pays a fine.

The smart contracts itself may include computer code that is used to verify if the behavior of the vehicles satisfies the actions specified in the smart contract. For this purpose, the computer code in the smart contract may contact other vehicles, and/or measurement equipment along the road to verify the behavior of vehicles.

The embodiments also disclose a system comprising nodes that are configured as hosts of a distributed ledger, the permission to access the distributed ledger being location based. The nodes may for example be nodes of one or more Vehicular Ad Hoc Networks. Still further, for each relevant location, a different block chain may be dynamically created. Nodes of the system may store a copy of a block chain for each of the different locations. When vehicles revisit a location, the block chain may be updated.

The architecture of the distributed ledger may scale up. However, the distributed ledger can also be used in a scenario where one or multiple nodes are central servers. A central server may for example store all the local block chains.

The embodiments also disclose a method of providing a distributed ledger, the permission to access the distributed ledger being location based.

Permission to access the distributed ledger may for example depend on physical closeness. For example, a group of vehicles may announce a smart contract to a nearest road side unit. A node of the distributed ledger may incorporate a smart contract into the ledger and may share the smart contract with other nodes. In such way all nodes may know the actions to be performed by all vehicles in an efficient and distributed manner.

The embodiments disclosed herein may also be used for fleet management of some vehicles, e.g. for fleet management of delivery drones, e.g. unmanned aerial vehicles (UAV) utilized to transport packages, food or other goods.

An additional use for a location based distributed ledger is envisioned for shops and shopping malls. A location based distributed ledger can be set up which is permissioned for shops in e.g. a shopping mall. Users may access the distributed ledger once they are close to the shopping mall. With access to the ledger users can directly buy and pay for products. Furthermore, advertising for products and corresponding discounts may be published on the block chain in the form of smart contracts. A user may also use a second distributed ledger, and assets may be transferred from this ledger to the location based distributed ledger. This is useful to pay for instance for products that are advertised on the location based ledger. Smart contracts can handle the interaction between these ledgers through the user that has received permission to access the location based distributed ledger.

FIG. 1 describes an exemplifying situation in which two autonomous vehicles 11, 12 interact with each other and with a road side unit 13 via vehicular communication to find consensus concerning their next actions. The two autonomous vehicles 11, 12 meet each other at a location that is controlled by road side unit 13. The two vehicles 11, 12, when they are within the communication range of road side unit 13, form a location based group of vehicles 14. In order to increase driving safety, the two autonomous vehicles 11, 12 communicate with each other via vehicular communication. Here, for example, the two autonomous vehicles 11, 12 exchange their individual velocities and they decide that the faster vehicle has priority over the slower vehicle, i.e. that the slower vehicle will slow down to give the faster vehicle priority. They record this consensus concerning their next actions in a smart contract 15 and transmit this smart contract 15 to road side unit 13 that stores smart contract 15 in a location based distributed ledger 16.

FIG. 2 describes an exemplifying situation in which two autonomous vehicles 21, 22 interact with each other via vehicular communication to find consensus concerning their next actions. The two autonomous vehicles 21, 22 meet each other at a location that is controlled by road side unit 23. The two vehicles 21, 22, when they are within the communication range of road side unit 23, form a location based group of vehicles 24. In order to increase driving safety, the two autonomous vehicles 21, 22 communicate with each other via vehicular communication. Here, for example, the two autonomous vehicles 21, 22 exchange their individual velocities and they decide that the faster vehicle has priority over the slower vehicle, i.e. that the slower vehicle will slow down to give the faster vehicle priority. They record this consensus concerning their next actions in a smart contract 25 and store smart contract 25 in a location based distributed ledger 26. Each autonomous vehicle comprises an own copy of this location based distributed ledger 26.

FIG. 3 describes a further exemplifying situation in which an autonomous vehicle 31 interacts with a road side unit 32 via vehicular communication to find consensus concerning the vehicle's next actions. The vehicle 31, when it is within the communication range of road side unit 32, is part of a location based group of vehicles 33 that is related to road side unit 32. Road side unit 32 controls a stop sign 34 that is located at a crossing situated within the region controlled by road side unit 32. In order to increase driving safety, the autonomous vehicle 31 communicates with road side unit 32 via vehicular communication. Here, for example, the autonomous vehicles 31 indicates to the road side unit 32 its geographical position and that it will stop at the stop sign 34. Autonomous vehicle 31 and road side unit 32 record this consensus concerning the vehicle's next action in a smart contract 35 and road side unit 32 stores this smart contract 35 in a location based distributed ledger 36.

FIG. 4 shows an example of two road side units that are communicatively coupled to close vehicles and a central server. A vehicle group 41 consisting of three vehicles 41a, 41b, and 41c and a vehicle group 42 consisting of three vehicles 42a, 42b, and 42c is shown. Each of these vehicle groups 41, 42 may obtain consensus on the next actions to be taken on the road, and announce the consensus in the form of a smart contract to the nearest road side unit. Vehicle group 41 announces the consensus to road side unit 43. Vehicle group 42 announces the consensus to road side unit 45. Road side unit 43 and road side unit 45 are communicatively coupled to each other and share a distributed ledger 44, 46. The permission to access the distributed ledger 44, 46 depends on physical closeness to the respective road side unit. Road side unit 43 and road side unit 45 are communicatively coupled to a central server 47. Central server 47 stores a full copy of the distributed ledger covering all data obtained from all road side units of the complete system, e.g. a full block chain. Road side unit 43 and road side unit 45 need not store a full copy of the distributed ledger.

FIG. 5 shows an example of Vehicle Ad Hoc Peer-to-Peer Networks. A vehicle group 51 consisting of three vehicles 51a, 51b, and 51c and a vehicle group 52 consisting of three vehicles 52a, 52b, and 52c are formed via vehicular communication. Each of these vehicle groups may obtain consensus on the next actions to be taken on the road, and announces the consensus in the form of a smart contract to the other vehicles in the group. Vehicle group 51 stores smart contracts in a location based distributed ledger that is distributed over vehicles 51a, 51b and 51c. Vehicle group 52 stores smart contracts in a location based distributed ledger that is further distributed over vehicles 52a, 52b and 52c. The permission to access a distributed ledger depends on physical closeness of the vehicles to each other. The two vehicle groups 51 and 52 thus form Vehicular Ad Hoc Networks. Vehicles 51a, 51b, and 51c are nodes of a first Vehicular Ad Hoc Network related to vehicle group 51. Vehicles 52a, 52b, and 52c are nodes of a second Vehicular Ad Hoc Network related to vehicle group 52. Each of the Vehicular Ad Hoc Networks can be seen as an Ad Hoc Peer-to-Peer Network. According to this example, there are no road side units or central servers involved in the storage of the distributed ledger. However, in alternative embodiments, also road side units and/or central servers may participate in the Vehicular Ad Hoc Networks.

FIG. 6 schematically describes an example wherein, in a merging area of a road, vehicles 63a-d in a certain first area 61 get a rule on a smart contract and make a consensus of their behavior in a second area 62. In the merging area of the road, there exist four lanes, lane0, lane1, lane2, and lane3. To make a consensus of their behavior in the second area 62, the vehicles 63a-d decide, e.g. which of the vehicles may enter in the first area 61 within a certain period of time. Still further, the vehicles 63a-d decide by when the vehicles 63a-d may enter in the second area 62. Still further, the vehicles 63a-d determine behaviors of each vehicle in the second area 62. In the case of the merging area of road, there is a road side unit associated with the first area 61 that stores a database 64 that covers the first area 61 or outskirts of the first area 61. This database stores smart contracts to provide the basic rule of the behavior in the second area 62. By means of a smart contract vehicles in the first area 61 must participate in a process to make a consensus about their behaviors in second area. In the second area 62 vehicles have to follow a determined-behavior based on the consensus they found in the first area 61. The database has a memory storing geographical information concerning the vehicles (e.g. location of the vehicles, whether or not they are inside the first and/or second area, etc.), smart contracts, and previous consensus results. A smart contract comprises a basic rule of the behavior in the second area 62 and an advanced rule.

An example of a basic rule defines that a) the faster vehicle has a priority, b) that the smaller number lane has a priority (e.g. 15 sec), c) that a vehicle has to change the speed to pass the second area 62 with keeping a certain distance to each other (e.g. 50 m), and that d) a vehicle only can change the lane to the upper number lane if necessary.

An example of an advanced rule defines a) an arrangement based on the previous consensus result and b) emergent situations and the retrieval.

FIG. 7 schematically describes a method of providing a location based distributed ledger in the exemplifying scenario of FIG. 6. At 701, vehicles entering or before entering the first area receive the geographical information, the basic rule (or basic and advanced rule) and the previous consensus result. At 702, the vehicles provide own planning track information (speed, lane and time) to the database. At 703 the database receives all planning track information in the first area (e.g. the number is fixed by the database with a camera and informed to all vehicles) and consensus of the behaviors in the second area is made.

FIG. 8 schematically describes an alternative method of providing a location based distributed ledger in the exemplifying scenario of FIG. 6. At 801, vehicles entering or before entering the first area receive the geographical information, the basic rule (or basic and advanced rule) and the previous consensus result. At 802, the vehicles broadcast own planning track information (speed, lane and time) to all other vehicles. At 803, the vehicles receive all planning track information in the first area 61 (e.g. the number is fixed by the database with a camera and informed to all vehicles) and make a consensus of the behaviors in the second area 62.

A smart contract on the database may be stored on a block chain and may connect to the Private or Consortium type block chain network maintained by a few controllers like an authority and trusted entity, e.g. a traffic authority or a financial institute. Multi-signatures of the controllers are required to change the smart contract.

The geographical information may be updated by a part of the road side unit.

The previous consensus result may be stored in the database with a signature of the database after making a consensus, and may optionally be provided to vehicles entering or before entering in the first area to be used for calculating own planning track information at each vehicle.

All vehicles may have a distributed ledger which is interoperable with the block chain network of the smart contract, or create a distributed ledger with the contract to the database as a turning point.

FIG. 9 schematically describes an embodiment of an electronic device 900 that may be used in context of the embodiments. The electronic device 900 comprises a CPU 901 as processor. The electronic device 900 further comprises an UMTS/LTE interface 904 and a WiFi-interface 905. These units 904, 905 act as I/O interfaces for data communication with external devices such as for car-to-car communication or for communication between a car and a road side unit. The electronic device 900 further comprises a GPS sensor 921 for obtaining location information. The electronic device 900 further comprises a data storage 902 (e.g. a hard drive or solid state drive) and a data memory 903 (e.g. a RAM). The data memory 903 is arranged to store or cache data or computer instructions for processing by processor 901. The data storage 902 is arranged as a storage for a distributed ledger.

It should be noted that the description above is only an example configuration. Alternative configurations may be implemented with additional or other sensors, storage devices, interfaces or the like. For example, in alternative embodiments, the processor 901 may also be coupled to further sensors that are used in automated or autonomous driving such as CCD cameras, TOF cameras, or the like.

A road side unit may have a similar structure as that disclosed in FIG. 9. In addition or alternatively to the I/O interfaces 904, 905 in FIG. 9 a server acting as road side unit may also be connected to other road side interfaces or to a central server by means of Ethernet connections. Still further, a road side unit that has a static location must not necessarily include a GPS sensor such as 921 in FIG. 9. The static location of a road side unit may also be preconfigured in the unit.

FIG. 10 schematically describes a further use case in which the vehicles are delivery drones. Three delivery drones 100a, 100b, 100c interact via vehicle communication. The delivery drones find consensus concerning their flight paths and flight behavior and store this consensus in a database 101. The database 101 may be a distributed ledger, e.g. a block chain. The block chain may be used to record consensus in the form of smart contracts. Still further, the database may be used to record transactions related to actions such as picking up and/or loading off parcels. The delivery drones may form Peer-to-Peer Ad Hoc Networks, or they may interact with ground based units (just as cars interact with road side units) and central servers, or use combinations of these techniques.

A distributed ledger may also be used for fleet management of some vehicles, e.g. for fleet management of delivery drones, e.g. unmanned aerial vehicles (UAV) utilized to transport packages, food or other goods.

It should be recognized that the embodiments describe methods with an exemplary ordering of method steps. The specific ordering of method steps is however given for illustrative purposes only and should not be construed as binding.

It should further be recognized that the division of the electronic device into units (such as exemplified in FIG. 9) is only made for illustration purposes and that the present disclosure is not limited to any specific division of functions in specific units.

In the embodiments described above, a method for controlling an electronic device, such as a digital camera device is described. The method can also be implemented as a computer program causing a computer and/or a processor to perform the method, when being carried out on the computer and/or processor. In some embodiments, also a non-transitory computer-readable recording medium is provided that stores therein a computer program product, which, when executed by a processor, such as the processor described above, causes the method described to be performed. All units and entities described in this specification and claimed in the appended claims can, if not stated otherwise, be implemented as integrated circuit logic, for example on a chip, and functionality provided by such units and entities can, if not stated otherwise, be implemented by software. For example, CPU 201 of the embodiment of FIG. 9 may be implemented by a respective programmed processor, field programmable gate array (FPGA), or the like.

In so far as the embodiments of the disclosure described above are implemented, at least in part, using a software-controlled data processing apparatus, it will be appreciated that a computer program providing such software control and a transmission, storage or other medium by which such a computer program is provided are envisaged as aspects of the present disclosure.

Note that the present technology can also be configured as described below.

(1) An electronic device that is configured as a host of a distributed ledger, the permission to access the distributed ledger being location based.

(2) The electronic device of (1), wherein the permission to access the distributed ledger depends on physical closeness.

(3) The electronic device of (1) or (2), wherein a vehicle is assigned to a distributed ledger based on its distance to other vehicles or based on its distance to a road side unit.

(4) The electronic device of anyone of (1) to (3), wherein the physical closeness is verified by each of the members of a distributed ledger.

(5) The electronic device of anyone of (1) to (4), wherein the electronic device is further arranged to contribute to different ledgers as it moves from one location to another.

(6) The electronic device of anyone of (1) to (5), wherein the distributed ledger is designed as a block chain.

(7) The electronic device of anyone of (1) to (6), wherein the distributed ledger is a private permissioned ledger for a location.

(8) The electronic device of anyone of (1) to (7), wherein the vehicular communication data stored by the distributed ledger comprises consensus information.

(9) The electronic device of anyone of (1) to (8), wherein the distributed ledger stores vehicular communication data.

(10) The electronic device of anyone of (1) to (9), wherein the distributed ledger records a smart contract between a group of vehicles.

(11) The electronic device of (10), wherein a smart contract defines a basic rule for the behavior of a group of vehicles in a defined area.

(12) The electronic device of anyone of (1) to (11), wherein the distributed ledger records geographical information, previous consensus results, and/or feedback on the execution of a smart contract.

(13) The electronic device of (9), wherein a smart contract specifies computer code that is used to verify if the behavior of vehicles in a group of vehicles satisfies actions specified in a smart contract.

(14) A system comprising nodes that are configured as hosts of a distributed ledger, the permission to access the distributed ledger being location based.

(15) The system of (14), wherein the nodes are nodes of one or more Vehicular Ad Hoc Networks.

(16) The system of (14) or (15), wherein, for each relevant location, a different block chain is dynamically created.

(17) A method of providing a distributed ledger, the permission to access the distributed ledger being location based.

(18) The method of (17), wherein permission to access the distributed ledger depends on physical closeness.

(19) The method of (17) or (18), wherein a group of vehicles announces a smart contract to a nearest road side unit.

(20) The method of anyone of (17) to (19), wherein a node of the distributed ledger incorporates a smart contract into the ledger and shares the smart contract with other nodes.

(21) A computer program comprising program code causing a computer to perform the method according to anyone of (17) to (20), when being carried out on a computer.

(22) A non-transitory computer-readable recording medium that stores therein a computer program product, which, when executed by a processor, causes the method according to anyone of (17) to (20) to be performed.

ELECTRONIC DEVICES, SYSTEMS AND METHODS FOR VEHICULAR COMMUNICATION

Information

Publication Number

Date Filed

Date Published

Inventors

Original Assignees

CPC

International Classifications

Abstract

Description

Claims

Priority Claims (1)

PCT Information