A blockchain-based asynchronous federated learning method in a vehicle networking

Abstract

The application relates to a kind of blockchain-based asynchronous federated learning methods in Internet of Vehicles, belong to mobile communication technical field.The method is: task publishing vehicle initiates learning task to the blockchain network maintained by roadside unit in edge network, and uploads initial model to the blockchain network simultaneously;Task training vehicle establishes connection with adjacent roadside unit;Task training vehicle obtains current to-be-verified and to-be-aggregated model from edge network;Task training vehicle obtains updated global model according to global model obtained in local data set training;Task training vehicle establishes connection with adjacent roadside unit in edge network, and uploads to the blockchain network.After uploading successfully, roadside unit returns success information to task training vehicle;Until learning task converges, task publishing vehicle sends task termination information to roadside unit, and the task training ends.Vehicle can collect data in real time for machine learning through vehicle-mounted sensor, and does not need to worry about privacy leakage problem.

Description

TECHNICAL FIELD

[0001] The application belongs to the technical field of mobile communication, and relates to a blockchain-based asynchronous federated learning method in Internet of Vehicles. BACKGROUND

[0002] In recent years, the rapid development of machine learning has enabled its rapid application in various fields. Machine learning belongs to the field of artificial intelligence and is the core of artificial intelligence and a key technology for autonomous driving. With the development of Internet of Vehicles technology, network connection between vehicles, people and roadside units is achieved, providing a big data foundation for machine learning.

[0003] In Internet of Vehicles, data is scattered. Due to the "data island" phenomenon caused by data privacy issues, traditional machine learning cannot collect valuable data of a large number of vehicles for training. Federated learning is currently the main method to solve the problem of data privacy. Federated learning is a distributed learning technology that allows users to train locally and upload the trained model parameters to a central server for aggregation, thereby ensuring that private data remains local and is not leaked. Due to its distributed nature and structural characteristics, federated learning can be well integrated with blockchain. Blockchain has been widely used to solve security problems in distributed scenarios and can provide anti-tampering and traceability of model data for federated learning.

[0004] However, there are many problems in the application of federated learning in Internet of Vehicles: 1) Traditional federated learning is synchronous learning, and the model aggregation process needs to wait for the local training of most users to end. In the Internet of Vehicles scenario, user vehicles are often unstable due to their mobility. This synchronous learning method will frequently fail the model aggregation, resulting in a slow learning process; 2) Frequent interaction in federated learning will cause huge communication pressure and high communication cost; 3) Although federated learning protects local data from being leaked, the uploaded model contains data characteristics. Due to the exposure of the central server, the model can be easily intercepted, and through certain technical means, the data can be restored from the model, posing a privacy and security risk.

[0005] In view of the above problems, the application designs a blockchain-based asynchronous federated learning architecture for Internet of Vehicles, establishes a network model and a learning framework, etc. The architecture is a decentralized network composed of an edge layer and a user layer, which well solves the problem of distributed machine learning in a vehicle mobility scenario and realizes asynchronous distributed machine learning while protecting the data privacy of user vehicles. Under this architecture, vehicles can collect data in real time through vehicle-mounted sensors for machine learning without worrying about privacy leakage. The model obtained through machine learning can be used to guide technologies such as autonomous driving and provide intelligent services for vehicles. SUMMARY

[0006] In view of this, the purpose of the present application is to provide a blockchain-based asynchronous federated learning method in the Internet of Vehicles, which is used to solve the distributed asynchronous learning method and vehicle privacy protection in the Internet of Vehicles. User vehicles can collect road data information in real time through vehicle-mounted sensors, and share learning models through the architecture for intelligent services such as automatic driving.

[0007] To achieve the above purpose, the present application provides the following technical solutions:

[0008] In the first aspect, the present application provides a blockchain-based asynchronous federated learning architecture according to the Internet of Vehicles scenario and vehicle data privacy protection requirements. The implementation process of the scheme is as follows:

[0009] S1: The task publishing vehicle initiates a learning task to the blockchain network maintained by the roadside unit in the edge network, and uploads the initial model to the blockchain network;

[0010] S2: The task training vehicle establishes a connection with the adjacent roadside unit;

[0011] S3: The task training vehicle obtains the current to-be-verified and to-be-aggregated model from the edge network, and selects k models for aggregation as a global model;

[0012] S4: The task training vehicle trains the global model obtained in S3 according to the local data set to obtain an updated global model;

[0013] S5: The task training vehicle establishes a connection with the adjacent roadside unit in the edge network, uploads the updated global model in S4 to the blockchain network through the roadside unit. After successful uploading, the roadside unit returns success information to the task training vehicle;

[0014] S6: All task training vehicles repeat steps S2-S5 until the learning task converges, and the task publishing vehicle sends task termination information to the roadside unit, and the task training ends.

[0015] In the second aspect, the present application establishes a blockchain-based asynchronous federated learning model in the Internet of Vehicles in step S1, which includes the following network elements: 1) terminal mobile devices, including task publishing vehicles and task training vehicles; 2) edge service layer, including edge computing nodes such as roadside units.

[0016] Roadside units (RSUs) are edge nodes deployed near roads that host servers to provide communication, storage and computing resources for vehicles. In the present embodiment, RSUs are connected by optical fibers to form an edge computing network. End devices are user vehicles, including task publishing vehicles and task training vehicles, which are connected to RSUs wirelessly. The blockchain uses the Tangle network with a directed acyclic graph (DAG) architecture to implement asynchronous learning. Since vehicles are mobile, the blockchain is maintained by RSUs, which are fixed in geographical location and have more abundant storage and communication resources.

[0017] Task publishing vehicles publish training tasks, such as road sign image recognition for intelligent driving, through RSUs and upload initial model parameters. The RSU adds the task and initial model to the genesis block in the DAG chain. In the DAG network, all iterative training models will point to the genesis block.

[0018] In a third aspect, the vehicle access edge network method is provided in step S2. Since vehicles are moving in real time while RSUs are fixed in location, a moving vehicle may need to connect to different RSUs when accessing the edge network, so the vehicle needs to select an RSU when accessing the edge network. The vehicle access edge network method includes the following steps: 1) the vehicle searches for nearby connectable RSUs and obtains their geographical location, communication quality, number of connected vehicles and data queuing situation; 2) the vehicle calculates the communication cost with each connectable RSU, which considers the above four information, and selects the RSU with the minimum communication cost to establish a connection.

[0019] In a fourth aspect, the asynchronous distributed learning framework is provided in step S3. The Tangle network based on DAG is used, in which each block in the DAG contains a global model that is obtained by aggregating and updating the local training of all blocks pointed to by the block. That is, each block, when added to the DAG network, will point to some tips to be verified, then verify and aggregate the models to perform local training. The block will become a tip after being connected to the DAG network.

[0020] The task training vehicle first acquires all the tips in the DAG network (blockchain network) through the RSU, wherein each tip contains a global model uploaded to the blockchain by other task training vehicles. The task training vehicle tests the models of all the tips according to a local data set, selects k models with the highest accuracy to aggregate a global model as a to-be-trained model. If there is only a genesis block in the DAG network, that is, the task is just published, the initial model in the genesis block is directly taken as the local to-be-trained model. The weighted average aggregation method is used for aggregation of the k models, wherein the weight value is positively correlated with the accuracy.

[0021] In the fifth aspect, the embodiment of the present application provides a local training method in step S4. The global model aggregated in step S3 is taken as an initial model for this round of training, and the task training vehicle trains a new model using a local data set. The new model is packaged into a block and sent to the edge network, wherein the block header includes the value of k and the hash values of the selected k blocks, and the block body includes the new global model.

[0022] In the sixth aspect, the embodiment of the present application provides a model uploading method in step S5. Due to the real-time mobility of the vehicle, the connection between the vehicle and the roadside unit in the edge network may be disconnected at any time, so the vehicle needs to check the current connection condition each time it communicates with the edge network. The task training vehicle first checks the current connection, and if the connection is disconnected, it re-establishes the connection with a roadside unit in the edge network using the method in step S2. Then, the block packaged locally in S4 is sent to the roadside unit, and the roadside unit perfects the block header information (including the version number, timestamp, random number, block hash value, etc.) and uploads it to the blockchain. After successful uploading, the roadside unit returns success information to the task training vehicle.

[0023] In the seventh aspect, the embodiment of the present application provides a task training termination method in step S6. After the task training vehicle successfully completes step S5, it receives the success information returned by the roadside unit, which contains a flag indicating whether the task is completed. In the case where the learning task has not converged, the task training vehicle receives a flag indicating to continue training, and it can continue to perform steps S2-S5 to complete the next task iteration. The task publishing vehicle requests the roadside unit for the update of the current blockchain in real time, and observes the accuracy of the model through the local test set. When it considers that the model accuracy meets the expectation or has converged, it sends a stop task request to the roadside unit. The roadside unit broadcasts the stop request to the whole network, and the task training ends.

[0024] The beneficial effects of the present application are that the present application first establishes a federated learning model of a vehicle networking scene, which is composed of an intelligent edge layer and a vehicle user layer. Then, an asynchronous federated learning architecture based on a directed acyclic graph (DAG) is proposed, and a related learning method is proposed based on the architecture. The architecture can realize asynchronous federated learning in the vehicle networking scene while protecting the data privacy of vehicles. Under the architecture, vehicles can collect data in real time through vehicle-mounted sensors for machine learning, and do not need to worry about privacy leakage. The model obtained by machine learning can be used for technologies such as autonomous driving to provide intelligent services for vehicles.

[0025] Other advantages, objects, and features of the present application will be understood by those skilled in the art from the following specification in conjunction with the appended claims, and will be apparent to one skilled in the art from the following description. The objects and other advantages of the present application can be realized and obtained by the following description. BRIEF DESCRIPTION OF DRAWINGS

[0026] In order to make the objects, technical solutions and advantages of the present application clearer, the preferred detailed description of the present application will be combined with the drawings, in which:

[0027] Figure 1 A block chain-based asynchronous federated learning network model diagram;

[0028] Figure 2 A vehicle access edge network flowchart;

[0029] Figure 3 A DAG-based distributed asynchronous learning framework and block structure schematic diagram;

[0030] Figure 4 A block chain-based vehicle networking asynchronous federated learning execution flowchart. DETAILED DESCRIPTION

[0031] The embodiments of the present application are described below through specific specific examples, and those skilled in the art can easily understand other advantages and effects of the present application from the disclosure of the present specification. The present application can also be implemented or applied by different specific embodiments, and the details in the specification can be modified or changed based on different views and applications without departing from the spirit of the present application. It should be noted that the diagrams provided in the following examples only illustrate the basic concept of the present application in a schematic manner, and the following examples and features in the examples can be combined with each other without conflict.

[0032] The accompanying drawings are for illustrative purposes only and are schematic diagrams, not actual pictures. They should not be construed as limiting the invention. To better illustrate the embodiments of the invention, some parts in the drawings may be omitted, enlarged, or reduced, and do not represent the actual product dimensions. It is understandable to those skilled in the art that some well-known structures and their descriptions may be omitted in the drawings.

[0033] In the accompanying drawings of the embodiments of the present invention, the same or similar reference numerals correspond to the same or similar components. In the description of the present invention, it should be understood that if terms such as "upper," "lower," "left," "right," "front," and "rear" indicate the orientation or positional relationship based on the orientation or positional relationship shown in the drawings, they are only for the convenience of describing the present invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, the terms used to describe positional relationships in the drawings are only for illustrative purposes and should not be construed as limiting the present invention. For those skilled in the art, the specific meaning of the above terms can be understood according to the specific circumstances.

[0034] Figure 1 A schematic diagram of a possible structure of the asynchronous federated learning system according to an embodiment of the present invention is shown. Figure 1 As shown, this network considers a four-layer architecture, including a DAG layer, an edge layer, a user layer, and a local training layer. The user layer consists of user vehicles, including task-issuing vehicles with learning task requirements and task-training vehicles with local data. These vehicles communicate wirelessly with Roadside Units (RSUs). The edge layer, composed of RSUs, provides communication, computing, and storage resources for user-layer vehicles. RSUs are connected via fiber optic cables. The edge layer maintains the DAG blockchain, which contains the global model uploaded by the vehicles. Task-issuing vehicles publish training tasks to the blockchain via the RSUs and package the initial model into a genesis block. Task-issuing vehicles monitor the model training progress via the RSUs, and when the model accuracy reaches the required level, they issue a stop-training request. Task-training vehicles obtain the global model information from the DAG blockchain via the RSUs, train using local data to obtain a new global model, and upload it to the DAG blockchain via the RSUs.

[0035] 1. Vehicles connect to the edge network

[0036] When a vehicle sends a request to access the edge network, it must first establish a connection with the RSU at the edge layer. Figure 2The flow chart of vehicle accessing edge network is shown. When a vehicle accesses an edge network for the first time, it needs to be registered, and the supervisor (government agency or organization) will issue a certificate to the vehicle. When the vehicle needs to access the edge network, it first requests information of all RSUs within the communication range, including the geographical location of the RSU, the communication quality, the number of connected vehicles, and the data queuing situation, etc. The vehicle will calculate the communication cost of establishing a connection with all RSUs based on the above information, and select the RSU with the minimum cost for connection. After successful connection, the target RSU will verify the identity of the vehicle, and if it is a registered vehicle, it will respond to the request. The request includes task publishing request, task termination request, model acquisition request and model upload request, etc.

[0037] 2. Distributed asynchronous learning architecture based on DAG

[0038] Figure 3 The distributed asynchronous learning architecture based on DAG and the block structure are shown. Figure 3 In the DAG blockchain, each block (except the genesis block) is generated by a task training vehicle and packaged by an RSU for uploading; each block is composed of a block header and a block body, the block header includes a version number, a timestamp, a random number, a block hash, a number of pointing blocks k and the hashes of all pointing blocks; the block body includes the model obtained by local training of the vehicle. A block points to k other blocks, indicating that the model in this block is a new model obtained by aggregating the models of k blocks and then locally training, i.e., a global model. The pointing also means verification and recognition of the legality of the block.

[0039] The genesis block is generated by a task publishing vehicle, packaged by an RSU for uploading, and contains an initial model; all blocks will eventually point to the genesis block; a trusted block is a block that is pointed to (verified) by enough blocks, meaning that the trusted block is tamper-proof; a to-be-verified block is usually a transitional block at the front end of the DAG chain that has not been pointed to (verified) by enough blocks, and will eventually become a trusted block as it is continuously pointed to (verified) by newly added blocks; an isolated block is usually a malicious block that will not be accepted (pointed to) by other blocks due to factors such as identity and accuracy, and thus will be discarded as it cannot be converted from a to-be-verified block to a trusted block.

[0040] As new blocks are continuously added to the chain, the DAG chain grows, the to-be-verified blocks gradually become trusted blocks, and the newly added blocks are supplemented as to-be-verified blocks waiting for connection by subsequent new blocks. Therefore, the model accuracy in the to-be-verified blocks in the DAG chain will gradually increase to convergence. Vehicles only need to aggregate the models of part of the to-be-verified blocks in the current DAG chain for local training, and do not need to wait for other vehicles, so all vehicles can participate in training at any time and can exit offline at any time.

[0041] 3. Local training of vehicles

[0042] Figure 3 The detailed process of vehicle local training is shown. The task training vehicle first establishes a connection with the RSU, and then sends a model acquisition request to the RSU to acquire all the current to-be-verified blocks in the DAG chain. Secondly, the vehicle verifies the model accuracy in all the to-be-verified blocks through the local data set, sorts them in descending order, and selects the top k as the pointing blocks (verification, aggregation). Then, the models in the selected k to-be-verified blocks are aggregated into a global model by weighted average according to the accuracy, and the higher the accuracy, the greater the weight. The aggregated model is trained using the local data to update a new global model. Thirdly, a new global model is generated, the block header includes the k value and the hash values of the k pointing (verification, aggregation) blocks, and the block body includes the new global model. Finally, the newly generated block is sent to the RSU for packaging, the RSU adds the version number, timestamp, random number and block hash in the block header, and uploads it to the DAG chain, and returns the on-chain success information to the vehicle. The task training vehicle can start a new round of training. When the model accuracy meets the requirements or has converged, the task publishing vehicle will send a task stop request to the RSU. The RSU will send the task stop information to the task training vehicle when it establishes a connection with the RSU.

[0043] 4. System flow

[0044] Figure 4 The execution flowchart of the blockchain-based Internet of Vehicles asynchronous federated learning is shown, and the specific steps are as follows:

[0045] S401: System initialization;

[0046] S402: The task publishing vehicle publishes a task and an initial model to the roadside unit;

[0047] S403: Generate a task publishing request list;

[0048] S404: The roadside unit receives the request;

[0049] S405: Verify the identity information of the vehicle requesting, if passed, go to the next step, otherwise repeat step S404;

[0050] S406: Verify the request content, if it is a task publishing request, execute S407. If it is a task termination request, execute S411. If it is a model uploading request, execute S414. If it is a model acquisition request, execute S422. Otherwise, repeat step S404;

[0051] S407-S410: Receive the task publishing request, generate a DAG chain for the task and add a genesis block, and broadcast the information to the edge network, and then execute step S428;

[0052] S411-S413: Receiving the task termination request, terminating the learning task, broadcasting information to the edge network, and then executing step S428;

[0053] S414-S4121: Receiving the model upload request, first checking whether the task is terminated. If terminated, generate task termination information and return it to the requesting vehicle. If not terminated, package the vehicle-generated block and upload it to the DAG chain, then return success information to the vehicle and broadcast the block information to the edge network. Then execute step S428;

[0054] S4022-S427: Receiving the model acquisition request, first checking whether the task is terminated. If terminated, generate task termination information and return it to the requesting vehicle. If not terminated, generate a tips list of the tips in the current DAG chain and send it to the requesting vehicle. Then execute step S428;

[0055] S428: Sub-task ends, return to step S404;

[0056] S429: The task training vehicle connects to the roadside unit and acquires the current model;

[0057] S430: Generate a model acquisition request list and send it to the roadside unit;

[0058] S431: Wait to receive information returned by the roadside unit;

[0059] S432: Determine whether the returned information is a task end or a model information. If it is a task end, execute step S443. If it is a model information, execute step S433;

[0060] S433: Extract all model information from the acquired current tips;

[0061] S434: Verify the accuracy of all received models using the local data set and sort them in descending order of accuracy;

[0062] S435: Select the top k high-precision models as the aggregated model;

[0063] S436: Weighted average the k models to form a global model, with higher precision resulting in higher weight;

[0064] S437: Update the global model obtained by training the local data set;

[0065] S438: Pack the k value and the hash value of the selected k blocks as the block header, and the new global model as the block body into a block;

[0066] S439: Connect to the roadside unit and upload the packaged block;

[0067] S440: generate a model uploading request list and send it to the roadside unit;

[0068] S441: wait for receiving information returned by the roadside unit;

[0069] S442: determine whether the returned information is a task end or an uploading success information, if it is the task end, execute step S443, if it is the uploading success information, execute step S444;

[0070] S443: the task training is ended;

[0071] S444: continue the next round of training and execute step S429;

[0072] S445: the task publishing vehicle acquires the current model training situation;

[0073] S446: generate a model acquiring request list and send it to the roadside unit;

[0074] S447: test and observe the model training situation with the local data set;

[0075] S448: check whether the model reaches the accuracy requirement or converges, if it reaches the requirement or converges, execute step S449, otherwise execute step S445;

[0076] S449: send a task termination information to the roadside unit;

[0077] S450: generate a task termination request list and send it to the roadside unit;

[0078] S451: the running is ended;

[0079] It should be noted that in this document, the terms "comprise", "comprising", or any other variant thereof are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements in the list, but can also include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element preceded by "comprises a" does not, without more constraints, foreclose the existence of additional identical elements in the process, method, article, or apparatus that comprises the recited element.

[0080] Those skilled in the art can clearly understand the above-mentioned embodiment method can be realized by means of software and the necessary general hardware platform, of course, also can be through hardware, but many cases the former is the better implementation. Based on such understanding, the technical solutions of the present application essentially or say to the prior art contribution part can be embodied in the form of software product, the computer software product is stored in a storage medium (such as ROM / RAM, disk, optical disc), including several instructions to make a terminal (may be a mobile phone, computer, server, air conditioner, or network side equipment, etc.) executes the method for switching cell described in several embodiments of the present application.

[0081] Finally, it is pointed out that the above embodiments are only used to illustrate the technical solutions of the present application rather than limit, although the present application is described in detail with reference to the preferred embodiments, those skilled in the art should understand that the technical solutions of the present application can be modified or replaced by equivalent, without departing from the purpose and scope of the present technical solutions, which should be covered in the scope of claims of the present application.

Claims

1. An asynchronous federated learning method based on blockchain in the Internet of Vehicles, characterized in that: The method includes the following steps: S1: The task-issuing vehicle initiates a learning task to the blockchain network maintained by the roadside units in the edge network, and simultaneously uploads the initial model to the blockchain network; based on a two-layer edge-client network, the edge layer contains roadside units, and the client is the user vehicle; the roadside units provide communication, computing, and storage resources for the vehicle, and the vehicle is responsible for task issuance and training; a Tangle blockchain network with a Directed Acyclic Graph (DAG) architecture is used to achieve asynchronous learning; the task-issuing vehicle issues the training task through the roadside units; the roadside units generate a genesis block of the task and the initial model and add it to the DAG chain; S2: The training vehicle establishes a connection with a nearby roadside unit; S3: The task training vehicle obtains the current models to be verified and aggregated from the edge network, and selects k models from them to aggregate as the global model; S4: The task training vehicle trains the global model obtained in S3 based on the local dataset to obtain the updated global model; S5: The training vehicle establishes a connection with the nearby roadside unit in the edge network and uploads the updated global model from S4 to the blockchain network through the roadside unit; after successful upload, the roadside unit will return a success message to the training vehicle. S6: All training vehicles repeat steps S2 to S5 until the learning task converges. The task issuing vehicle sends the task termination information to the roadside unit, and the training of the task ends.

2. The asynchronous federated learning method based on blockchain in the Internet of Vehicles according to claim 1, characterized in that: In step S2, a method for vehicle access to an edge network is provided; the proposed method for vehicle access to an edge network includes the following steps: 1) The vehicle searches for nearby roadside units that can be connected and obtains their geographical location, communication quality, number of connected vehicles, and data queuing status; 2) The vehicle calculates the communication cost with each roadside unit that it can connect to. This communication cost takes into account four factors: geographical location, communication quality, number of connected vehicles, and data queuing status. The roadside unit with the lowest communication cost is selected to establish a connection.

3. The asynchronous federated learning method based on blockchain in the Internet of Vehicles according to claim 2, characterized in that: In S3, an asynchronous learning framework is provided; a Tangle network based on a Directed Acyclic Graph (DAG) is adopted, where each block in the DAG contains a global model; when each block is added to the DAG network, it points to some block tips to be verified, and then verifies and aggregates its model for local training; after being connected to the DAG network, the block becomes a block to be verified; the task training vehicle first obtains all current tips in the DAG network from the edge network, tests the models of all tips according to the local dataset, selects the k models with the highest accuracy to aggregate into a global model, which is used as the model to be trained; a weighted average aggregation method is used to aggregate the k models, where the weight values ​​are positively correlated with their accuracy.

4. The asynchronous federated learning method based on blockchain in the Internet of Vehicles according to claim 3, characterized in that: In S4, a local training method is provided; The global model aggregated in step S3 is used as the initial model for this round of training. The task training vehicle will use the local dataset to train and obtain a new model. The new model is packaged into a block and sent to the edge network.

5. The asynchronous federated learning method based on blockchain in the Internet of Vehicles according to claim 4, characterized in that: In step S5, a model uploading method is provided; the task training vehicle first checks the current connection. If the connection is broken, it re-establishes a connection with a roadside unit in the edge network using the method in step S2; then, the block packaged locally in step S4 is sent to the roadside unit, which completes the block header information and uploads it to the blockchain. After successful upload, the roadside unit will return a success message to the training vehicle.

6. The asynchronous federated learning method based on blockchain in the Internet of Vehicles according to claim 5, characterized in that: In step S6, a method for terminating task training is provided. The task issuing vehicle requests the current blockchain update status from the roadside unit in real time and observes the model's accuracy through its local test set. When it believes that the model's accuracy has reached the expected level or has converged, it sends a stop task request to the roadside unit. The roadside unit broadcasts the stop request across the entire network, and the task training ends. Otherwise, the task training vehicle will continue to execute steps S2 to S5 to complete the next task iteration until it receives a stop task request.

Images