Figure 1:
Figure 2:
Figure 3:
Figure 4:
Figure 5:
Figure 6:
Figure 7:
Figure 8:
Figure 9:
Figure 10:
Figure 11:
Figure 12:
Figure 13:
Figure 14:
Figure 15:
The STRIDE threat model of the proposed architecture
| IoT layer: lightweight sensor nodes | Cloud layer: data preprocessing and blockchain gateway | Blockchain layer: HLF data storage | Application layer: web/mobile apps | |
|---|---|---|---|---|
| Asserts | Raw data, device identity, keys, local backup, and communication channel | User privileges, preprocessed data, vehicle classification models, keys, end-points, user and device logs, and communication channel | Immutable data, channels configuration, keys, gateway, chaincode, ledger state, audit logs, consensus, and communication channel | Application data, end-user privileges, and business logic |
| Threats | Device spoofing, eavesdropping, node compromise, man-in-the-middle, and SD card extraction | Data leakage, API abuse, user privilege escalation, data tampering, man-in-the-middle, eavesdropping, and model abuse | Malicious peer, chaincode bugs, channel, gateway abuse, misconfiguration, and consensus manipulation | XSS, session hijacking, authentication bypass, data leakage, and insecure endpoints |
| Mitigations strategies | Data encryption (TLS/SSL for transmission; AES for SD card), secure boot and firmware signing, tamper-resistant housing, use session keys, and limit physical ports | Role-based access control in cloud services, input validation, API authentication, model access control, and encrypt data | Used channel ACL, chaincode audit, enforced endorsement policies, monitored peer behavior, and transaction logs | Enforced MFA, strict session expiry, CSRF tokens, sanitized all user inputs, and rate-limited external API calls |
Research questions and contributions
| S. No. | Research questions | Research contributions |
|---|---|---|
| 1 | How can the inefficiency, transparency, and security challenges in the current Tanzania vehicle speed detection systems be addressed? | Demonstrated how IoT and blockchain technologies can be employed to implement an automated, transparent, and secure vehicle speed data collection system. |
| 2 | How can IoT and blockchain technologies be integrated for the vehicle speed data collection domain? | Pioneered the integration of IoT and blockchain technologies, representing the first known effort to develop such a combined architecture in the vehicle speed detection domain. |
| 3 | How can general-purpose vehicle speed data be collected in Tanzania’s highways? |
|
| 4 | How can a low-cost, scalable, and rural-friendly system for collecting vehicle speed in Tanzania be implemented? | Proposed a cost-effective design that is physically and performance scalable, employing lightweight IoT nodes compatible with rural environments. |
Comparison with the existing systems
| Reference | Architecture type | Application context | IoT device types | Data processing and storage | Blockchain parameters | Strengths/limitations |
|---|---|---|---|---|---|---|
| [42] | Generic | Generic | N/A | N/A | N/A | Served as the foundation for IoT-blockchain integration studies |
| [33] | Specific Two-layer | Agriculture | Full node | Blockchain and Off-Chain Storage IoT layer processing | Private Ethereum Consensus not specified | Full nodes are not well-suited for farm environments. The cost of deploying full nodes may not be affordable to smallholder farmers |
| [43] | Specific Three-layer | Agriculture | Light node | Cloud processing Blockchain Storage | Ethereum Consensus not specified | The application layer is not specified in the design |
| [44] | Specific Two-layer | Energy trading | Full node | Cloud storage and processing | Private Ethereum IBFT 2.0 | Centralized storage contradicts blockchain’s decentralization goals and the absence of an application layer |
| [45] | Specific Four-layer | IoT security | Light node | Off-Chain (processing and storage), Blockchain (hash storage) | HLF as a service | Support a varied type of sensors depending on the requirement. Can be applied in more than one domain area |
| [46] | Specific Three-layer | Environmental monitoring | Full node | Off-Chain (processing and storage) and Blockchain storage | HLF 2.4, Golang Chaincode, CouchDB state database | The application layer is not specified in the design |
| [24] | Specific Two-layer | IoT security | Full node | Blockchain | Polygon-based blockchain network, PoS/PBFT consensus | Unclear architecture description, difficult to understand its structure and implementation |
| [47] | Not presented | Supply chain | Light node | Blockchain | Ethereum, PoW consensus | Model architecture is not presented; only ER and flowchart diagrams are presented |
| [48] | Specific Three-layer | Healthcare | Light node | Not specified | Private and consortium blockchain with unspecified platform | No PoC prototype to validate the proposed architecture |
| [35] | Specific Three-layer | Healthcare | Light node | Off chain | Unspecified blockchain technology | No PoC prototype to validate the proposed architecture |
| [49] | Specific Four-layer | Healthcare | Full node | Data stored in the cloud | Ethereum-based blockchain with type unspecified | Complex with lots of overhead, an integrity verification process |
| This work | Specific Four-layer | Vehicle speed detection | Light node | Cloud preprocessing, blockchain storage, application-specific processing | HLF-based consortium blockchain, Raft consensus, CouchDB state db | The first effort in vehicle speed detection used HLF channels to build a consortium network and introduced a versatile application layer for general-purpose speed data |
Experiment configuration setup
| Configurations | NN values | NR values |
|---|---|---|
| Configuration 1 (varied NR, fixed NN) | Fixed 60 | [1, 3, 5, 10, 20, 30, 40, 50] |
| Configuration 2 (varied NN, fixed NR) | [1, 6, 12, 18, 24, 36, 48, 60] | Fixed 50 |
Design decision factors for integrating IoT and blockchain technologies
| S. No. | Building blocks | Design factors for consideration | Design decisions |
|---|---|---|---|
| 1 | Type of IoT devices |
|
|
| 2 | Application type and context | Depending on the specific application of vehicle speed detection across various organizations, blockchain implementation can be permissioned, permissionless, or hybrid, depending on security, transparency, and access requirements. | Since the application involves multiple governmental and nongovernmental organizations, a permissioned blockchain is utilized to establish a consortium blockchain network, ensuring controlled access, data integrity, and secure collaboration among authorized entities. |
| 3 | Data types, storage, and processing requirements |
|
|
| 4 | Blockchain parameters |
|
|
| 5 | Security requirements | What security services are needed? | Security services needed are confidentiality, integrity, authenticity, and key management. |
Channels implemented within the blockchain network
| Channel name | Channel description | Organizations | Data shared |
|---|---|---|---|
| C1 | Speed limit law enforcers |
|
|
| C2 | Passengers transporters |
|
|
| C3 | Cargo transporters |
|
|
| C4 | Regulatory and registration authorities |
|
|
| C5 | Road safety, research, development, and management organizations |
|
|
Comparison with the existing centralized solutions
| Work | Performance | Scalability | Purpose | Transparency | Privacy and security |
|---|---|---|---|---|---|
| [16] | >90% accuracy | Need to be improved | Traffic law enforcement | Not transparent | Concerned due to centralization |
| [50] | Not available | Not addressed | Over-speeding detection | Not transparent | Not addressed |
| [51] | >90% performance | Scalable | Speed limit enforcement | Not transparent | Unclear how they are ensured |
| [52] | >90% performance | Moderately scalable | Traffic management | Not transparent | Concerns due to centralized design |
| [53] | 89.3% performance | Not addressed | Over-speeding detection | Not transparent | Not addressed |
| [54] | Not available | Not addressed | Monitoring vehicle speed and traffic jams | Not transparent | Not addressed |
| This work | 1 s latency, 1 record/s throughput, 0.07% error (varying NR) | Scalable (physical and performance) | General purpose | Transparency via DLT | Ensured via blockchain, HLF channels, and more (Table 6) |