idnits 2.17.1 draft-zhang-t2trg-accident-blockchain-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 29, 2020) is 1206 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Li 3 Internet-Draft X. Zhang, Ed. 4 Intended status: Informational J. Fan 5 Expires: July 2, 2021 Inner Mongolia University 6 December 29, 2020 8 Architecture for collecting traffic accident information based on 9 blockchain 10 draft-zhang-t2trg-accident-blockchain-00 12 Abstract 14 Blockchain is a distributed technology, and it uses cryptography and 15 hash functions to store data in a chain to ensure that data are 16 tamper-resistant and traceable. So, this document proposes an 17 architecture for collecting traffic accident information based on 18 blockchain. At the same time, this document describes the working 19 method of collecting traffic accident information under this 20 architecture. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on July 2, 2021. 39 Copyright Notice 41 Copyright (c) 2020 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Relate work . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. System structure . . . . . . . . . . . . . . . . . . . . . . 5 59 3.1. Perception layer . . . . . . . . . . . . . . . . . . . . 6 60 3.2. Edge computing layer . . . . . . . . . . . . . . . . . . 6 61 3.3. Service layer . . . . . . . . . . . . . . . . . . . . . . 6 62 4. Scheme design . . . . . . . . . . . . . . . . . . . . . . . . 7 63 4.1. Traffic accident information query . . . . . . . . . . . 7 64 4.2. Traffic accident information return . . . . . . . . . . . 7 65 4.2.1. Resource fragmenting method . . . . . . . . . . . . . 7 66 4.2.2. Resource Naming Method . . . . . . . . . . . . . . . 8 67 4.3. RSUs consensus . . . . . . . . . . . . . . . . . . . . . 8 68 4.4. Traffic accident information storage . . . . . . . . . . 9 69 5. Discuss . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 70 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 71 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 72 8. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 10 73 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 74 10. Informative References . . . . . . . . . . . . . . . . . . . 11 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 77 1. Introduction 79 With the development of society, there are more and more vehicles on 80 the road, and a problem that follows is that the incidence of traffic 81 accidents is also increasing. The frequent occurrence of traffic 82 accidents has brought a serious impact on human life, and has brought 83 certain pressure on the relevant traffic departments to deal with 84 traffic accidents. The handling of traffic accidents must be timely, 85 and the evidence must be obtained correctly, so as to avoid traffic 86 jams, secondary accidents and legal disputes. Therefore, how to use 87 the existing technology to quickly, correctly and effectively deal 88 with traffic accidents has become a very important issue. 90 The most important thing to deal with traffic accidents is to collect 91 traffic accident information (also known as "resources"). At 92 present, the main methods of collecting traffic accident information 93 are manual and automatic. Among them, manual methods include 94 measuring tape, witness investigation, and on-site photographing. 95 The automatic method is to use the camera at the intersection. These 96 methods require a long time, and cause certain difficulties for rapid 97 recording, rapid evacuation of traffic, subsequent accident analysis 98 and liability determination. 100 In the past few years, with the development of wireless communication 101 technology and the automobile industry, the Vehicular Ad Hoc Network 102 (VANET) has developed significantly [Misra2009]. Based on the VANET 103 researchers have proposed a large number of related applications, 104 which are divided into safety-related applications and comfort- 105 related applications [Eze2014]. These applications mainly use the 106 cooperation between vehicles to transmit messages. The driving 107 recorder is an instrument that records the video image and sound of 108 the vehicle during driving. If a traffic accident occurs in front of 109 the vehicle, it can provide strong evidence for handling the traffic 110 accident. Resources can also be collected through cooperation 111 between vehicles. It can be seen that the use of vehicle-to-vehicle 112 collaboration in the VANET can transmit driving recorder?s data to 113 relevant departments, which is beneficial to better handling of 114 traffic accidents. 116 Most of the resources transmitted is used as evidence. It is 117 necessary to ensure that the data transmitted to the relevant 118 transportation department are true, confidential, and not tampered, 119 and traceable. However, in the communication process, resources 120 security is the main concern, including the safety protection issues 121 in transmission process, the security issues of centralized storage 122 in the data center, the access control and privacy protection. 124 Blockchain is a distributed technology. It uses cryptography and 125 hash functions to store data in a chain to ensure that data are 126 tamper-resistant and traceable. And the technology uses a consensus 127 protocol to ensure data consistency. Therefore, blockchain 128 technology can be applied to the VANET environment to solve the 129 security problem and remove the dependence on trusted central 130 entities. However, the process of consensus has to solve the large 131 computational problem which cannot be done on computing resources 132 constrained vehicles. As a new type of technology, Mobile Edge 133 Computing (MEC) can be used not only to offload computationally 134 intensive tasks from mobile devices to edge networks, but also to 135 optimize processing before sending data to the core network, and to 136 provide edge cloud services for mobile users at the edge. 138 Therefore, this document proposes an architecture for collecting 139 traffic accident information based on blockchain. It uses blockchain 140 to ensure that resources are tamper-resistant and traceable, and uses 141 edge computing to solve the large computational problem of blockchain 142 consensus process. 144 In section 2, some current researches on collecting transaction 145 accident information are described, and their shortcomings are 146 analyzed. Section 3 proposes the structure of this document. 147 Section 4 describes the working method of collecting traffic accident 148 information in the framework proposed in this document. Section 5 149 discusses how the architecture guarantees the security of VANET. 150 Section 6 summarizes the full document. 152 2. Relate work 154 With the increase of vehicles on the road, the number of traffic 155 accidents has also increased. The traditional methods of collecting 156 traffic accident information are manual methods-pulling a measuring 157 tape, witnessing investigation, and taking pictures on the spot, 158 which takes a long time and is not conducive to the rapid evacuation 159 of traffic and rapid recording of the scene. Therefore, there are a 160 large number of researchers in collecting traffic accident 161 information. 163 Among these studies, one type of research is to use web-based methods 164 to obtain accident information. Users upload the accident 165 information to the server of the relevant transportation department 166 through the browser, and the relevant transportation department 167 obtains the traffic accident information from the server as the basis 168 for handling the traffic accident. Lobont et al. collect basic 169 information of accidents in a web-based traffic accident collection 170 system, including time and location [Lobont2013]. In a web-based 171 traffic accident collection system, Williams et al. collect 172 information on the severity of accidents, vehicle types, casualties, 173 road conditions, weather conditions, and light conditions 174 [Williams2015]. Another form of such research is the use of smart 175 phones. CrashData [Derdus2014] proposed by Derdus et al. is an 176 application based on mobile smart phones. The application can upload 177 the basic information of the traffic accident to the server. This 178 type of research must be connected to the Internet and requires users 179 to participate in actively uploading information, but users may not 180 upload resources voluntarily. 182 Another type of research is to install fixed infrastructure on both 183 sides of the road to obtain traffic accident information. In the 184 traffic accident investigation and management system based on GPS 185 VRS, GIS road database and stereo vision technology proposed by 186 Qingwu H et al. [Hu2011], the traffic accident information is mainly 187 obtained through GPS VRS and GIS road database, and then restored 188 using stereo vision technology. In the system for collecting traffic 189 accident information based on ultrasound and ZigBee wireless 190 transmission technology proposed by Song H et al. [Song2014], the 191 state of the vehicle during a traffic accident is measured by 192 ultrasound, including information such as speed and direction. This 193 type of research is limited by the location of fixed infrastructure, 194 and traffic accident information cannot be collected where there is 195 no fixed infrastructure. 197 Other research is firstly obtaining traffic accident information 198 through various sensors on the vehicle, and then using the VANET to 199 transmit the traffic accident information to the relevant traffic 200 department. In the literature [Abduljalil2012], Abduljalil FM et al. 201 use on-board angle sensors, airbag sensors, cameras, GPS sensors, 202 etc. to obtain traffic accident information, and then use Wi-Fi, 203 GPRS, 3G, WIMAX, 4G-LTE wireless transmission technology to transfer 204 traffic accident information to the relevant department. In the 205 VWaas service architecture proposed by Hussain R et al. 206 [Hussain2013], when a traffic accident occurs, the surrounding 207 vehicles use the car?s camera to capture the traffic accident 208 information, and then send the captured content to the centralized 209 server facility. In this process, the vehicle directly sends traffic 210 accident information to the server via 3G/4G or transmits the traffic 211 accident information to the RSUs (Road Side Units) via DSRC, and then 212 the RSU transmits the information to the RSUs server. 214 Among the above methods for collecting traffic accident information, 215 the web-based method requires users to upload traffic accident 216 information to a server, which must be connected to the Internet, and 217 the time for collecting information is relatively long. Based on the 218 way roadside infrastructure collects traffic accident information, 219 limited by the fixed location of the infrastructure, it is impossible 220 to collect traffic accident information in areas not covered by the 221 infrastructure. The method of collecting traffic accident 222 information based on vehicle sensors and the VANET requires the 223 participation of RSUs. In the above three methods of collecting 224 traffic accident information, only the information after the traffic 225 accident can be collected, and the information before the traffic 226 accident cannot be obtained. The analysis of the accident and the 227 determination of responsibility after the accident have certain 228 difficulties. And there is no guarantee that the collected traffic 229 accident information is not been tampered with and can be traced to 230 the source. 232 3. System structure 234 This document proposes a security architecture for collecting traffic 235 accident information based on blockchain. The architecture consists 236 of three layers, namely perception layer, edge computing layer, and 237 service layer. The perception layer comprises vehicle and RSU, 238 together forming blockchain network. The edge computing layer 239 provides computing resources and edge cloud services for the 240 perception layer. The service layer includes cloud services and 241 blockchain. 243 3.1. Perception layer 245 A driving recorder is installed on the vehicle, which can record the 246 traffic accident information of the vehicle passing position. 247 Because of the constraint of computing resource and the mobility, the 248 vehicle cannot perform all blockchain functions, including wallet 249 (save address and private key), miner (mining), complete blockchain 250 (save all blockchain data), network routing (validate and propagate 251 transaction block information, discover and maintain connections to 252 peer nodes). In this document, vehicle performs the functions of 253 wallet and network routing. 255 The RSU connects each other by wired communication, forming stable 256 blockchain network which can ensure a unique ledger for collecting 257 traffic accident information. Therefore, all blockchain functions 258 are performed on the RSU. Even while one vehicle is moving, it can 259 communicate with RSU directly or through other vehicles. 261 3.2. Edge computing layer 263 There are lots of transactions occurred for collecting traffic 264 accident information. If all the consensus work of the blockchain 265 transaction is completed in RSU, it will inevitably affect the 266 network performance and bring high delay. Therefore, this document 267 offloads the computationally intensive work to MEC, and the result is 268 returned to the RSU after completion. MEC is also responsible for 269 handling other computationally intensive work, such as video or image 270 processing, etc. 272 3.3. Service layer 274 The traffic accident information recorded by the driving recorder is 275 video, which has a large amount of data and is not suitable for 276 storage in blockchain of RSUs. Because the blockchain is distributed 277 storage, each blockchain node stores all the data, which consumes 278 lots of storage resources. So, the document stores the traffic 279 accident information on the cloud server, which can not only store 280 the data permanently, but also facilitate the inspection and evidence 281 collection by the traffic police department. 283 So, for data stored in the service layer, part of the data which are 284 tamper-resistant and traceable, such as traffic accident data, 285 traffic violation data, etc. are stored using blockchain. The other 286 part of data is stored on the cloud service. 288 4. Scheme design 290 Based on the above architecture, the working method of collecting 291 traffic accident information includes 4 steps, including traffic 292 accident information query, traffic accident information return, RSUs 293 consensus, and traffic accident information storage. The working 294 methods of collecting traffic accident information are as follows. 296 4.1. Traffic accident information query 298 The traffic police department initiates a traffic accident 299 information inquiry request based on the time and location of the 300 traffic accident. The query request is sent to the vehicles driving 301 on the road through the RSUs. Because it is uncertain which vehicles 302 have captured the traffic accident information, in order to enable 303 more vehicles within the communication range of the RSU to receive 304 the traffic accident information query request, the document uses the 305 flooding method to send the query request. At the same time, delay 306 tolerant network technology is used to forward query requests to 307 vehicles that are not within the communication range of RSU by using 308 moving vehicles. 310 4.2. Traffic accident information return 312 The vehicle receives the traffic accident information query request 313 and checks whether the traffic accident information is recorded 314 locally. If recording, extract the traffic accident information from 315 the driving recorder and transmit it to the nearest RSU. If the 316 vehicle does not directly communicate with the RSUs in a single hop, 317 it is forwarded through the intermediate vehicle. 319 The vehicle is in a moving state. If the traffic accident 320 information recorded by the driving recorder is directly disseminated 321 on the network, the probability of transmission failure will be very 322 high, and the network performance will be affected. Therefore, this 323 document processes the traffic accident information in fragments, and 324 then transmits the fragmented traffic accident information, and 325 finally aggregates it through the RSUs. 327 4.2.1. Resource fragmenting method 329 The resources need to be transmitted in fragments. However, the size 330 of the fragments must ensure that a complete resource can be 331 transmitted within the shortest communication time between vehicles. 332 Therefore, this document determines the size of resource fragments 333 according to the shortest communication time of vehicles on urban 334 roads. First, determine the shortest time for vehicle communication 335 on urban roads. The movement of vehicles on urban roads can be 336 divided into two types: same direction driving and reverse direction 337 driving. When two vehicles are driving in the same direction and in 338 the reverse direction on the city road at the same speed, the 339 communication time for them when driving in the reverse direction is 340 shorter. 342 Generally, vehicles on urban roads are not allowed to exceed the 343 prescribed speed. When the vehicle is traveling at the maximum speed 344 specified on the city road, the communication time between them is 345 the shortest. Therefore, the fragment size of the resource is 346 defined as the data size that can be transmitted in the shortest 347 communication time between vehicles, which can ensure that any 348 resource can be transmitted within the vehicle communication time 349 range. 351 4.2.2. Resource Naming Method 353 The traffic accident information after fragmentation is named 354 according to certain rules, which is convenient to distinguish from 355 other vehicles and to facilitate aggregation. The naming rules are 356 as follows: 358 NodeID_SerialNum_TotalNum_Time_Location 360 Among them, NodeID represents the ID of the node, that is, the 361 license plate number of the vehicle; SerialNum represents the serial 362 number of the traffic accident information fragment; TotalNum 363 represents the total number of traffic accident information 364 fragments; Time represents the time when the traffic accident 365 occurred; Location represents the location of the traffic accident, 366 that is, the latitude and longitude. 368 For the same traffic accident resource, the node ID can distinguish 369 which vehicle provides the resource, and the resource sequence number 370 and the total number of resource fragments can distinguish each 371 fragment of the resource provided by the vehicle. For the same car 372 (same node ID), even if the resources of multiple traffic accidents 373 are captured, different traffic accidents can be distinguished by the 374 time and location of the traffic accident. Moreover, each fragment 375 of the same traffic accident resource can be distinguished by the 376 resource sequence number and the total number of resource fragments. 378 4.3. RSUs consensus 380 The traffic accident information needs to be verified, agreed, and 381 added to the blockchain. The specific process is as follows: 383 a. When RSUs receive traffic accident information, they generate a 384 transaction based on the basic information and hash value of the 385 traffic accident information (NodeID, SerialNum, TotalNum, Time, 386 Location) and forward it to other RSUs. 388 b. Other RSUs in the blockchain network receive the transaction and 389 check whether the transaction is valid and the format is correct. 390 If the inspection meets the requirements, it is placed in the 391 transaction storage pool and forwarded to other RSUs. The other 392 RSUs that receive the transaction repeat the process. 394 c. The RSU that obtains the right to packaging the transactions in 395 the transaction storage pool into a block, and then mines the 396 block. The mining process needs to complete a large number of 397 calculations, and RSUs generally do not have the ability to 398 complete a large number of calculations, and the calculation 399 tasks need to be offloaded to edge computing. Edge computing 400 completes the calculation task and returns the result to the 401 RSUs. The RSUs sends the block to other RSUs to spread across 402 the entire network. 404 d. After receiving the block, other RSUs verify the block. If the 405 block is verified, the RSUs deletes the completed consensus 406 transaction from the transaction storage pool and the block being 407 mined, and at the same time adds it to the blockchain. 409 4.4. Traffic accident information storage 411 The RSUs aggregate the traffic accident information fragmented in the 412 blockchain. The aggregating process involves video processing, so 413 this process is also offloaded to edge computing to reduce the 414 workload of RSUs and increase its effectiveness. After the edge 415 computing completes the aggregation of the traffic accident 416 information, it sends the complete traffic accident information to 417 the RSUs. 419 The blockchain in RSUs cannot store all traffic accident information. 420 So it is uploaded to the cloud for storage, and the blockchain in the 421 RSUs only store the digest of traffic accident information. In order 422 to ensure the security of data in cloud, the data which are tamper- 423 resistant and traceable are stored using blockchain. While, other 424 data adopt the original storage method of the cloud, guaranteeing 425 security by cloud computing architecture. 427 5. Discuss 429 This section focuses on how the architecture guarantees the security 430 for collecting traffic accident information. 432 In this security architecture, vehicles and RSUs in the perception 433 layer together form blockchain network to improve the security for 434 collecting traffic accident information. However, traffic accident 435 information generated by the vehicle generally are stored in the 436 cloud or a centralized platform so as to provide data support for 437 related department. Considering a large amount of traffic accident 438 information, the perception layer does not have enough space to 439 store. Therefore, in this security architecture, the traffic 440 accident information is still stored in the cloud of the service 441 layer. In order to ensure the security of data in cloud, the data 442 which are tamper-resistant and traceable are stored using blockchain. 443 While, other data adopt the original storage method of the cloud, 444 guaranteeing security by cloud computing architecture. 446 At the perception layer, the main challenge is security of traffic 447 accident information during transmission. So, blockchain in the 448 perception layer is used to solve the security problem in the 449 transmission process. And the data solving the security problem in 450 transmission process need to be stored in perception layer 451 blockchain. By combining MEC, the perception layer can ensure the 452 security of traffic accident information in transmission process. 454 6. IANA Considerations 456 There are no IANA considerations related to this document. 458 7. Security Considerations 460 There are no Security Considerations related to this document. 462 8. Conclusion 464 This document proposes an architecture for collecting traffic 465 accident information based on blockchain. The architecture includes 466 three layers, namely perception layer, edge computing layer and 467 service layer. The perception layer ensures the security of VANET 468 data in the transmission process through the blockchain. The edge 469 computing layer provides computing resources and edge cloud services 470 for the perception layer. The service layer uses the combination of 471 traditional cloud storage and blockchain to ensure the security of 472 data. 474 9. Acknowledgements 476 This work was supported by the Inner Mongolia Autonomous Region 477 Science and Technology Achievements Transformation Project (No. 478 CGZH2018124). 480 10. Informative References 482 [Abduljalil2012] 483 Abduljalil, F., "A framework for vehicular accident 484 management using wireless networks", 2012 IEEE 13th 485 International Conference on Information Reuse & 486 Integration (IRI), 2012. 488 [Derdus2014] 489 Derdus, K. and V. Ozianyi, "A mobile solution for road 490 accident data collection", Proceedings of the 2nd Pan 491 African International Conference on Science, Computing and 492 Telecommunications (PACT 2014), 2014. 494 [Eze2014] Eze, E., Zhang, S., and E. Liu, "Centralized Conferencing 495 (XCON) Media Models", 2014 20th International Conference 496 on Automation and Computing, 2014. 498 [Hu2011] Hu, Q. and H. Wang, "A Framework for Traffic Accident 499 Scene Investigation with GPS VRS, Road Database and Stereo 500 Vision Integration", 2011 International Workshop on 501 Multi-Platform/Multi-Sensor Remote Sensing and Mapping, 502 2011. 504 [Hussain2013] 505 Hussain, R., Abbas, A., Son, S., Kim, K., Kim, K., and O. 506 Oh, "Vehicle witnesses as a service: Leveraging vehicles 507 as witnesses on the road in vanet clouds", 2013 IEEE 5th 508 International Conference on Cloud Computing Technology and 509 Science, 2013. 511 [Lobont2013] 512 Lobont, L., FILICHI, A., and L. POPESCU, "Improving 513 traffic safety using modern methods for accident data 514 collection", ANNALS OF THE ORADEA UNIVERSITY Fascicle of 515 Management and Technological Engineering, 2013. 517 [Misra2009] 518 Misra, S., Zhang, I., and S. Misra, "Guide to wireless ad 519 hoc networks", Springer Science & Business Media, 2009. 521 [Song2014] 522 Song, H., Ming, J., Tang, J., Zeng, D., Duan, w., and Z. 523 Yin, "Wireless Positioning System for Investigation of 524 Road Traffic Accidents", Proceedings of the International 525 Conference on Logistics, Engineering, Management and 526 Computer Science, 2014. 528 [Williams2015] 529 Williams, K., Idowu, P., and E. Olonade, "Online Road 530 Traffic Accident Monitoring System for 531 Nigeria", Transactions on Networks and Communications, 532 2015. 534 Authors' Addresses 536 Ru Li 537 Inner Mongolia University 538 Hohhot 010021 539 China 541 Phone: +86 15804712558 542 Email: csliru@imu.edu.cn 544 Xiaodong Zhang (editor) 545 Inner Mongolia University 546 Hohhot 010021 547 China 549 Phone: +86 15247168840 550 Email: cszxd@imu.edu.cn 552 Jun Fan 553 Inner Mongolia University 554 Hohhot 010021 555 China 557 Phone: +86 18686016307 558 Email: 250832228@qq.com