The literature survey raises some major queries:

  • • How to record traffic offenses in the absence of traffic wardens and cameras at any time of the day?
  • • How to develop such a distributed trusted environment for CC-IoV that holds offender trust as well?
  • • How to report the offensive events and prove them?

Based on the literature review reported in the literature survey, conclusions have been drawn (Table Al.l).

An auditable and trustworthy ledger of content sharing based on Blockchain hardly exists for the CC-IoV.

CC-IoV [16-21] work does not provide an auditable ledger of contents. The work in [15] has proposed a database of offenses along with patrolling traffic police vehicles. The Blockchain-based schemes [32-34] do not record the content shared among entities and that wastes the effective use of Blockchain in the scenario of a content-centric environment. The work in [35] proposed to record content object pointer in Blockchain which lacks in the trust issues because of the loss of data on producer end.

The proposed mechanisms in [28-30] are IP-based which need a stable connection to be established first. Although the proposed solutions in [39,40] have missed the essence of Blockchain in CC-IoV, provisioning of an auditable ledger of content shared to push entities towards honest participation in the network for content sharing.

The proposed edge-computing-based cooperative transaction validation for offensive events in Blockchain-enabled CC-IoV aims to achieve the following objectives:

  • • To develop a cooperative scheme that detects the offense by involving the BEN and vehicles and then raise a report against the offender.
  • • To develop a trusted transaction validation scheme in a distributed CC-IoV environment that performs validation with minimum delay and least control overhead.


This section presents the proposed scheme for the validation of events to transaction formation. First, it is worth mentioning and inculcating that data transfer among entities takes place with the help of packets transmission; each packet contains specific information from the sender, while the receiver makes some decision and steps over packet type. Packet formation and contents will be discussed in this section, which will allow receivers to make some decisions in completing the process of an event occurring to transaction validation for Blockchain. Then, we will provide an overview of the scheme in steps.

Generating packets

In CCN, content sharing takes place between producers and consumers using interest or data packets transfer. In our scheme, we have targeted the speed offense as the offending event and a key stakeholders’ producer is ‘offender node’ because it generates the information of speed offense on collection of sensory data; consumers are the ‘dealing authorities or TMA’ getting information prompted by the edge computing node and consuming the information to record offensive events and generate e-tickets for offenders. To achieve a fair and trusted working scheme, the details of packets shared and steps of data sharing follow.

Speeding vehicle info delivery

We assume that vehicles are equipped with speed sensors attached to their OBU. If a vehicle crosses over the speeding thresholds, OBU will start advertising its vehicle information packet until the offender’s speed is not inside the limits specified by the authorities; initially the packet contains the vehicle identification and speed. As the packet broadcast will only initiate after the speed violation, there will be no overhead on the network unless an offender commits the violation. One-hop neighbours will be the receiver of this packet. Receiving vehicles will start counting the vehicle information packet. If the received count is within specified limits, it will take no action considering an overtake activity or other emergency conditions; it will, however, generate and send offense reporting packet. In Figure 3.5, the packet formation and contents used in the delivery of offender vehicle information which helps to calculate and allocate bandwidth for data transmission is shown.

Reporting an offense

As receiving of the VehlnfoPkt is counted, if received count crosses the threshold, it ensures the vehicle is continuously violating the speed regulation

Packet formation of VehlnfoPKT

Figure 3.5 Packet formation of VehlnfoPKT.

Packet formation of reportOffPacket

Figure 3.6 Packet formation of reportOffPacket.

set by authorities or else some other activity like overtaking other vehicles is done by the packet originator. After the confirmation of the speed offense over packet count, the receiving neighbour will generate a report offense packet for BEN in its transmission range as shown in Figure 3.6. The same packet contains the reporting vehicle identification, offender’s identification, and speed at the time of the offense. Packet formation and contents with their data length are depicted in the following figure.

Validation of offense

As the report offense packet is only for BEN, only BEN will act on receiving the report offense packet, while the rest of the receiving nodes will discard the packet. BEN will maintain a local database to save the partial information of reporting vehicle identification, offender’s ID. and speed of offender, which will be the part of the transaction after a validation process. Transaction validation will be performed by asking the neighbouring nodes of BEN, which have recorded the offense of the reported offender in their local database. BEN will generate and advertise an interest packet validating the offense. Figure 3.7 depicts the packet formation and content data length for offense validation.

A Blockchain-enabled edge supported e-challan mechanism 95

Packet formation of ValidateOffense

Figure 3.7 Packet formation of ValidateOffense.

Reply of offense validation

On receiving an offense validation packet, vehicles will look up in their local data store for the existence of offender details. On successful retrieval of a matching record, vehicles will generate a reply packet for the validation of the offense confirming that the offender has violated the speeding regulation set by authorities and will advertise the packet targeting BEN. On receiving the reply packet of offense validation, officer node will merge the confirming vehicle’s information in matching the offender partially filled transaction. The packet formation of the reply validation packet is shown in Figure 3.8.

Finally, when m-numbers of transactions are collected by edge computing node, it will generate a block and will broadcast the block in the network for validation, which after successful validation is merged in the Blockchain.

System workflow of scheme

A summarised workflow of the scheme keeping the speeding offense in view with steps is as follows and is also depicted in the Figure 3.9:

Step-01: Vehicles will continuously monitor their speed sensor data. On violation of speeding limits, the vehicle will periodically advertise its identification and speed data by VehlnfoPkt.

Step-02: On receiving VehlnfoPkt, vehicles will maintain a record with the count of the packets received. If the packet received count reaches

Packet formation of ReplyValidateOffense

Figure 3.8 Packet formation of ReplyValidateOffense.

Working schema of the proposed system

Figure 3.9 Working schema of the proposed system.

the threshold, the offense will be reported to BEN with generating and broadcasting a reportOffPacket which contains the offender identification, violation speed, and reporter’s identification for future references.

Step-03: BEN will compile a new transaction with partial information extracted from the offense report packet and will validate the offense report by generating and sending an offense validation packet to validate the transaction.

Step-04: Validation request and interest receiving vehicles will generate and send a reply for offense validation by searching the existence of the offender details in their data table.

Step-05: BEN will add the confirming vehicle ID in the transaction for matching the offender ID.

Step-06: Finally, after m-number transactions, edge computing node will generate a block and will be merged in the Blockchain after successful validation consent from the Blockchain network.

< Prev   CONTENTS   Source   Next >