C-V2X-based vehicle-mounted mobile crowdsourcing computing platform

Abstract

The invention discloses a C-V2X-based vehicle-mounted mobile crowdsourcing computing platform, which relates to the technical field of intelligent traffic and edge computing, and comprises a road side unit (RSU), a mobile edge computing device (MEC), a vehicle-mounted unit (OBU) and an automatic driving unit (ADU). According to the invention, the C-V2X communication technology is utilized to schedule and distribute calculation tasks, and meanwhile, the mobile communication network (4G / 5G) is utilized to transmit large-capacity task data, so that the separation of a control flow and a data flow is realized. The RSU serves as a task scheduling center, is responsible for task segmentation and broadcasts task metadata through C-V2X; the OBU serves as a communication node to receive a task instruction; the ADU is used as a computing node, and tasks are executed by utilizing a containerized environment. Task scheduling is optimized through the low-delay characteristic of C-V2X, the task allocation problem under high-speed movement of vehicles is solved, and the utilization rate of computing resources in an intelligent traffic system is increased.

Description

Technical Field

[0001] This invention relates to intelligent transportation and vehicle networking technologies, specifically to a C-V2X-based in-vehicle mobile crowdsourcing computing platform. Background Technology

[0002] With the rapid development of autonomous driving and vehicle-to-everything (V2X) technologies, traditional crowdsourcing paradigms are gradually expanding into the field of intelligent transportation. In-vehicle crowdsourcing, as an emerging computing model, utilizes the computing and perception capabilities of vehicles to collect and process traffic environment data, demonstrating enormous application potential. However, as intelligent vehicles continue to evolve, traditional edge computing is gradually shifting towards in-vehicle computing. Conducting in-vehicle mobile crowdsourcing computing under existing communication models still faces numerous challenges. For example, uploading large amounts of sensor data not only encounters network bandwidth bottlenecks but also leads to frequent changes in system topology due to the high-speed mobility of vehicles, resulting in scheduling difficulties, perception redundancy, and limited computing resources under high-density vehicle conditions. This makes it difficult for traditional crowdsourcing computing architectures to meet the stringent requirements of intelligent transportation systems for real-time performance, reliability, and system-level scalability.

[0003] Most existing mobile crowdsourcing platforms rely on traditional cellular networks (such as 4G / 5G) for data transmission and task scheduling. While 5G networks offer higher data transmission rates, they still face significant limitations in real-world vehicle-based crowdsourcing scenarios, including system complexity, network load management, and privacy protection. In particular, to achieve accurate task allocation, existing systems often require vehicles to continuously report their location information to a central server, raising serious location privacy and security issues such as a lack of strict location authentication, vulnerability to man-in-the-middle attacks, and packet sniffing risks. Furthermore, solely relying on centralized cloud or edge computing for offloading can easily create single-point performance bottlenecks, failing to fully utilize the abundant idle computing resources of vehicles on the road, leading to resource waste, low processing efficiency, and difficulty adapting to highly dynamic road environments.

[0004] C-V2X, as a key technology for vehicle-to-everything (V2X) communication, has demonstrated excellent performance in reducing communication latency and improving reliability. However, current research on C-V2X systems mainly focuses on the perception and decision-making control layers, with relatively little research on the computing power layer. Experimental studies show that the bandwidth of C-V2X's direct communication interface is relatively limited, making it difficult to directly support the real-time transmission of large-scale computational task data (such as video streams and high-precision images). This limits its direct application in computationally intensive crowdsourcing tasks. Furthermore, vehicles frequently enter and exit the communication range of roadside units during movement. This dynamic condition significantly impacts the effectiveness of task scheduling strategies, requiring the system to possess real-time adaptability to maintain computational continuity. Existing static scheduling algorithms struggle to handle this high dynamism and lack optimization schemes specifically tailored to the constraints of the C-V2X communication framework.

[0005] Therefore, a novel platform architecture that combines C-V2X communication technology with mobile crowdsourced computing is urgently needed. This architecture not only needs to address the bandwidth limitations of C-V2X communication in high-volume data transmission but also needs to fully leverage its low latency and broadcast characteristics to optimize task scheduling and resource allocation. By constructing a mechanism that separates control flow from data flow—that is, using C-V2X to transmit scheduling instructions and using local area networks or cellular networks to transmit task data—the overall efficiency of the system can be effectively improved. Furthermore, the new architecture should be able to utilize the decentralized networking characteristics of C-V2X to reduce reliance on long-term connections to centralized infrastructure, thereby providing a higher level of location privacy protection for vehicles without sacrificing system performance, and promoting the practical application of in-vehicle collaborative computing in intelligent transportation systems. Summary of the Invention

[0006] Purpose of the invention: This invention provides a C-V2X-based vehicle-mounted mobile crowdsourcing computing platform to solve problems such as slow task scheduling response, low communication efficiency, and difficulty in adapting to frequent network topology changes caused by high-speed vehicle movement in existing vehicle-mounted mobile crowdsourcing computing.

[0007] Technical Solution: This invention discloses a C-V2X-based vehicle-mounted mobile crowdsourcing computing platform, comprising a roadside subsystem and a vehicle-mounted subsystem. The roadside subsystem includes a physically connected roadside unit (RSU) and a mobile edge computing device (MEC). The vehicle-mounted subsystem includes a physically connected onboard unit (OBU) and an autonomous driving unit (ADU). The MEC is equipped with a task segmentation module and a data warehouse for storing task images and function images, and is responsible for generating task scheduling instructions. The RSU is equipped with an RSU-side V2X proxy for converting the scheduling instructions generated by the MEC into broadcast messages conforming to the C-V2X protocol. The OBU is equipped with an OBU-side V2X proxy for listening to the C-V2X channel, filtering and parsing crowdsourcing task messages belonging to the vehicle. The ADU is equipped with a Serverless Function Computing Framework (OpenFaaS), which manages the lifecycle of function instances through the OpenFaaS gateway and is responsible for executing specific computing tasks.

[0008] The Roadside Unit (RSU) and On-Board Unit (OBU) of this invention can utilize existing vehicle-to-everything (V2X) devices, using a computer as a mobile edge computing (MEC). The RSU adds a V2X protocol header to the MEC's ​​scheduling instructions, creating a corresponding V2X message. This V2X message is then sent to the RSU, which broadcasts it. The OBU listens to the C-V2X channel on the ADU, continuously monitoring the port communicating with the ADU to see if any messages are received. It then checks if the vehicle ID in the message's protocol header matches its own. If it does, it parses the message, removing the encapsulated protocol header to obtain the original MEC scheduling instructions. This invention employs a heterogeneous communication architecture that separates control flow and data flow: at the control flow level, lightweight task scheduling signaling (control flow) is transmitted using the C-V2X direct communication interface; at the data flow level, high-bandwidth-consuming task data files and computational images (data flow) are transmitted using a mobile communication network or local area network.

[0009] The crowdsourcing calculation method of the above-mentioned vehicle-mounted mobile crowdsourcing computing platform is as follows:

[0010] Step 1: Task preprocessing and segmentation (segmentation here refers to manually splitting a function and then packaging the segmented sub-functions into function images; the data warehouse puts this data on the MEC and provides a port for the data to be pulled). The mobile edge computing unit (MEC) obtains the raw task data, splits the large-scale task data into multiple independent sub-tasks, and stores the segmented sub-task data and the corresponding computing function images in the repository, generating the corresponding data access address and function image address.

[0011] Step 2: Control command generation and broadcasting. The Mobile Edge Computing Unit (MEC) sends the data access address, function mirror address, and task parameters to the Roadside Unit (RSU). The V2X proxy module in the RSU encapsulates the above information into a custom C-V2X message frame and broadcasts it to vehicles within the coverage area via C-V2X.

[0012] Step 3: Task reception and parsing. The on-board unit (OBU) listens for and receives messages broadcast by the RSU through the C-V2X interface, parses out the task metadata, and forwards the task instructions to the autonomous driving unit (ADU) through the on-board internal network.

[0013] Step 4: Data stream separation transmission and computation. After receiving the instruction, the autonomous driving unit (ADU) pulls the computing environment and the data to be processed through the mobile communication network according to the function mirror address and data access address, and executes the computation task in the local containerized environment.

[0014] Step 5: Result Feedback. After completing the calculation, the Autonomous Driving Unit (ADU) feeds the result back to the Roadside Unit (RSU) via the Onboard Unit (OBU). The RSU then aggregates the result to the Mobile Edge Computing Unit (MEC) through a proxy module. This aggregation refers to combining the results of multiple subtasks into the original task result.

[0015] Further, the detailed method for task segmentation in step 1 is as follows: Step 1.1, for license plate recognition application scenarios, the original image containing multiple license plates is segmented into independent single license plate image regions; this invention can use the open-source software OpenALPR to first perform license plate detection, then perform OCR recognition on each detected license plate region, and then obtain license plate data; by deleting and adjusting the OpenALPR code, it is made to only perform license plate region detection, thus obtaining multiple single license plate image regions; that is, the data of the subtask is obtained;

[0016] Step 1.2: Decouple the task processing logic into two stages: license plate detection and character recognition;

[0017] Step 1.3: MEC distributes the segmented single license plate images as subtask units based on the current load.

[0018] Furthermore, the custom C-V2X message frame used for communication between the roadside unit (RSU) and the on-board unit (OBU) in step 2 includes a frame header and a message body. The frame header includes a start symbol, protocol version number, vehicle ID, UTC timestamp, message sequence number, and message body length. The message body includes a V2X message header, V2X version number, V2X vehicle ID, V2X timestamp, V2X message ID, V2X message length, V2X message number, V2X message type, and V2X message data.

[0019] Furthermore, both the V2X proxy module of the roadside unit (RSU) and the V2X proxy module of the on-board unit (OBU) include a message listening module and a message distribution module. The proxy captures HTTP requests from internal components (MEC or ADU) by listening to a specific port, parses and reassembles them into V2X messages for transmission; conversely, it restores the received V2X messages to HTTP requests and sends them to internal components.

[0020] Beneficial effects: Compared with the prior art, the present invention has the following advantages:

[0021] (1) This invention innovatively proposes a communication mechanism that separates control flow and data flow, effectively solving the contradiction between the limited bandwidth of C-V2X and the demand for crowdsourced large-scale data transmission. By using the C-V2X communication interface to transmit lightweight task scheduling signaling and using mobile network card communication (4G / 5G) to transmit large-capacity task data and computing images, it not only leverages the advantages of C-V2X's low latency and high reliability, ensuring millisecond-level task scheduling response, but also utilizes the high bandwidth characteristics of cellular networks to avoid C-V2X channel congestion caused by massive sensor data, significantly improving the overall communication efficiency of the system.

[0022] (2) The present invention can adapt to the highly dynamic network environment caused by the high-speed movement of vehicles. Traditional edge computing scheduling algorithms are difficult to cope with the topology changes caused by vehicles frequently entering and leaving the communication range. However, the present invention uses the broadcast characteristics of C-V2X to distribute tasks, without the need for a complicated connection establishment process. As soon as the vehicle enters the communication range, it can receive task instructions.

[0023] (3) This invention achieves elastic management of onboard computing resources by introducing serverless containerization technology. Deploying the OpenFaaS framework in the Autopilot Unit (ADU) allows computing tasks to be dynamically loaded and unloaded in the form of microservices. This not only enables vehicles to flexibly utilize idle computing power to participate in crowdsourcing tasks, improving the overall resource utilization of the intelligent transportation system, but also ensures, through container isolation mechanisms, that crowdsourcing computing tasks do not interfere with the vehicle's core autonomous driving functions, thus guaranteeing driving safety. Attached Figure Description

[0024] Figure 1 This is a schematic diagram of the system architecture and data interaction of a C-V2X-based vehicle-mounted mobile crowdsourcing computing platform provided in an embodiment of the present invention.

[0025] Figure 2 This is a schematic diagram of the frame header structure of a C-V2X message frame in an embodiment of the present invention.

[0026] Figure 3 This is a schematic diagram of the message body structure of a C-V2X message frame in an embodiment of the present invention.

[0027] Figure 4 This is a schematic diagram illustrating the processing flow and effect of the license plate recognition task in an embodiment of the present invention.

[0028] Figure 5 This is a schematic diagram comparing the computation time of executing the complete program and executing only the detection task on the MEC side in an embodiment of the present invention.

[0029] Figure 6 This is a schematic diagram showing the time consumption and data size of each stage of the execution of different license plate recognition sub-tasks by the vehicle-mounted ADU in an embodiment of the present invention. Detailed Implementation

[0030] The technical solution of the present invention will be described in detail below, but the scope of protection of the present invention is not limited to the embodiments described.

[0031] like Figure 1 As shown, the C-V2X-based vehicle-mounted mobile crowdsourcing computing platform of the present invention includes a roadside subsystem and a vehicle-mounted subsystem. The roadside subsystem includes a physically connected roadside unit (RSU) and a mobile edge computing device (MEC). The vehicle-mounted subsystem includes a physically connected onboard unit (OBU) and an autonomous driving unit (ADU). The mobile edge computing device (MEC) is equipped with a task segmentation module and a data warehouse for storing task images and function images, and is responsible for generating task scheduling instructions. The roadside unit (RSU) is equipped with an RSU-side V2X proxy for converting the scheduling instructions generated by the MEC into broadcast messages conforming to the C-V2X protocol. The onboard unit (OBU) is equipped with an OBU-side V2X proxy for listening to the C-V2X channel, filtering and parsing crowdsourcing task messages belonging to the vehicle. The autonomous driving unit (ADU) is equipped with the serverless function computing framework OpenFaaS, which manages the lifecycle of function instances through the OpenFaaS gateway.

[0032] The crowdsourcing calculation method of the above-mentioned vehicle-mounted mobile crowdsourcing computing platform is as follows:

[0033] Step 1: Task preprocessing and segmentation. The mobile edge computing unit (MEC) acquires the raw task data, segments the large-scale task data into multiple independent sub-tasks, and stores the segmented sub-task data and corresponding computation function images in the repository, generating the corresponding data access address and function image address.

[0034] Step 2: Control command generation and broadcasting. The Mobile Edge Computing Unit (MEC) sends the data access address, function mirror address, and task parameters to the Roadside Unit (RSU). The V2X proxy module in the RSU encapsulates the above information into a custom C-V2X message frame and broadcasts it to vehicles within the coverage area via C-V2X.

[0035] Step 3: Task reception and parsing. The on-board unit (OBU) listens for and receives messages broadcast by the RSU through the C-V2X interface, parses out the task metadata, and forwards the task instructions to the autonomous driving unit (ADU) through the on-board internal network.

[0036] Step 4: Data stream separation transmission and computation. After receiving the instruction, the autonomous driving unit (ADU) pulls the computing environment and the data to be processed through the mobile communication network according to the function mirror address and data access address, and executes the computation task in the local containerized environment.

[0037] Step 5: Result feedback. After the Autonomous Driving Unit (ADU) completes the calculation, it feeds back the calculation results to the Roadside Unit (RSU) through the Onboard Unit (OBU). The Roadside Unit (RSU) then aggregates the results to the Mobile Edge Computing Unit (MEC) through the proxy module.

[0038] The detailed method for task segmentation in step 1 of the above embodiment is as follows: Step 1.1, for license plate recognition application scenarios, the original image containing multiple license plates is segmented into independent single license plate image regions;

[0039] Step 1.2: Decouple the task processing logic into two stages: license plate detection and character recognition;

[0040] Step 1.3: MEC distributes the segmented single license plate images as subtask units based on the current load.

[0041] like Figure 2 and Figure 3 As shown, the custom C-V2X message frame used for communication between the roadside unit (RSU) and the on-board unit (OBU) in step 2 includes a frame header and a message body. The frame header includes a start symbol, protocol version number, vehicle ID, UTC timestamp, message sequence number, and message body length. The message body includes a V2X message header, V2X version number, V2X vehicle ID, V2X timestamp, V2X message ID, V2X message length, V2X message number, V2X message type, and V2X message data.

[0042] The message frame consists of a header and a body. The header is 24 bytes long and includes a start symbol (4 bytes) to identify the start of the frame, a protocol version number (4 bytes), a vehicle ID (4 bytes), a UTC timestamp (8 bytes), a message sequence number (4 bytes), a body length (4 bytes), and a variable-length body (0-996 bytes). The body consists of a V2X message header (4 bytes), a V2X version number (4 bytes), a V2X vehicle ID (4 bytes), a V2X timestamp (8 bytes), a V2X message ID (4 bytes), a V2X message length (4 bytes), a V2X message number (4 bytes), a V2X message type (4 bytes), and V2X message data (0-960 bytes).

[0043] The V2X proxy module of the roadside unit (RSU) and the V2X proxy module of the on-board unit (OBU) of this invention both include a message listening module and a message distribution module. The proxy captures HTTP requests from internal components (MEC or ADU) by listening to specific ports, parses and reassembles them into V2X messages for transmission; conversely, it restores the received V2X messages into HTTP requests and sends them to internal components. The system adopts a communication architecture that separates the control plane and the data plane: Control plane: uses C-V2X communication to transmit task scheduling signaling, resource requests and acknowledgment messages to ensure low-latency task distribution; Data plane: uses mobile communication networks (4G / 5G) to transmit high-bandwidth computing image files and task load data.

[0044] In this embodiment, the MEC serves as the system's computing core and data storage center. Internally, it houses a task segmentation module, a task scheduler, and a data warehouse. The data warehouse is divided into a raw data area, a sub-task data area, and a function mirror area. The MEC is responsible for preprocessing and segmenting the large-scale raw perception data collected from roadside sensors to generate micro-tasks suitable for processing by the onboard terminal. The RSU acts as a communication gateway connecting the wired network and the C-V2X wireless network. Internally, it runs a V2X proxy module and maintains a dynamic status table to record the online status, geographical location, and computing resource availability of vehicles within the communication coverage area in real time. The onboard terminal mainly includes the Onboard Unit (OBU) and the Automated Driving Unit (ADU). The OBU is equipped with a C-V2X communication module and runs a V2X proxy and task receiver on the OBU side, specifically responsible for monitoring the V2X communication channel and filtering and parsing broadcast messages from the RSU. As the node that actually performs computing tasks, the ADU is internally deployed with an OpenFaaS containerized computing environment and has heterogeneous network connectivity capabilities. That is, it connects to the OBU through an internal bus to obtain control commands, and connects to the Internet through a 4G / 5G module to pull large amounts of task data.

[0045] This embodiment uses Figure 4 Taking the automatic license plate recognition application in the example, this article details the entire workflow of crowdsourced computing.

[0046] First, once the vehicle enters the communication range, the OBU periodically broadcasts Basic Safety Messages (BSMs). The RSU's V2X agent receives and parses these messages, updating the vehicle's ID, latitude and longitude coordinates, speed, and other information in the status table (corresponding to...). Figure 1 (Step ①)

[0047] Subsequently, the task publisher on the MEC side acquires the original monitoring images. The task segmentation module uses an image segmentation algorithm to segment the original large image containing multiple vehicles into multiple independent single-vehicle license plate images. These sub-images are stored in the MEC's ​​file server and a corresponding Data URL is generated. At the same time, the MEC prepares the Docker image of the license plate recognition algorithm and generates a Function URL (corresponding to...). Figure 1 (Steps ②-④)

[0048] Next, the MEC sends metadata containing the Data URL and Function URL to the RSU. The RSU's V2X agent encapsulates this metadata into the aforementioned custom C-V2X message frame, and leverages the low latency of the C-V2X communication interface to send dispatch instructions (corresponding to) the target vehicle recorded in the status table. Figure 1 (Step 5)

[0049] After the vehicle's OBU captures the broadcast message through the V2X proxy, it parses the URL information and forwards the command to the ADU (corresponding to the vehicle's OBU) via the vehicle's local area network. Figure 1 Step 6). After receiving the instruction, the ADU uses mobile network communication (4G / 5G) to pull the algorithm image from the MEC or cloud according to the function image URL (skip if there is already a local cache), and downloads the license plate image data to be recognized at high speed according to the function data URL (corresponding to...). Figure 1 (Step ⑦)

[0050] Subsequently, ADU starts a recognition function instance in the OpenFaaS container, loads the downloaded image, executes the OCR algorithm, and outputs the recognized license plate number text.

[0051] Finally, the ADU sends the recognition result (text data) to the OBU. The OBU then uses C-V2X communication or mobile network communication (4G / 5G) to send the result back to the RSU. The RSU forwards it to the "result receiver" at the MEC for aggregation processing, thus completing the entire task loop (corresponding to...). Figure 1 (Steps ⑧-⑨)

[0052] The above embodiment constructs a prototype system based on a real C-V2X device and a high-performance computing unit to verify the feasibility of the technical solution of the present invention. Its specific configuration and application are as follows: 1. System Hardware and Environment Configuration The experimental environment built in this embodiment consists of two parts: roadside equipment and vehicle-mounted equipment. The specific configuration parameters are as follows:

[0053] Roadside Unit (RSU): HUALI intelligent roadside terminal is selected. This device supports GNSS high-precision positioning, operates in the 5.905GHz-5.925GHz frequency band, has a configured bandwidth of 10MHz or 20MHz, a measured communication latency of less than 20ms, an effective coverage range of over 800 meters, and a packet loss rate of less than 1%. The communication mode adopts PC5 (Mode 4) direct connection communication.

[0054] On-board Unit (OBU): HUALI intelligent vehicle terminal was selected and deployed on the test vehicle. Its communication parameters, frequency band, and operating mode are consistent with the RSU, and it is connected to the computing unit through the vehicle Ethernet interface.

[0055] Mobile Edge Computing (MEC) Device: This device uses a high-performance laptop to simulate an MEC server, connected to the RSU. Specific configuration includes an Intel Core i5-8250U processor (1.6GHz, 4 cores, 8 threads) and 8GB of RAM. To simulate a heterogeneous network environment, the device integrates a mobile network communication module, supporting 4G / 5G communication.

[0056] The Autonomous Driving Unit (ADU) utilizes the Baidu Apollo Autonomous Driving Development Kit (Apollo D-KITS Standard) as its onboard computing node. Its specific configuration includes an Intel Core i9-9900K processor (3.6GHz, 8 cores, 16 threads), 32GB of RAM, and an NVIDIA RTX 3060 dedicated graphics card. This unit deploys the OpenFaaS serverless computing framework and is equipped with an independent mobile network communication module for data transmission.

[0057] 2. Application Case Scenario Description This embodiment selects a typical license plate recognition task in an intelligent transportation system as the crowdsourcing computing scenario. Task Logic: The open-source project OpenALPR is used as the basic algorithm, and its computational logic is decoupled into two independent microservice functions: license plate detection and character recognition, as follows: Figure 4 As shown.

[0058] Scenario Design: The MEC (Multi-access Edge Computing) unit is responsible for running the license plate detection function, processing high-definition wide-angle images containing multiple vehicles captured by roadside cameras, locating the license plate area in the image, and segmenting it into independent sub-images (each sub-image is approximately 4.95KB to 6.22KB in size). Each segmented license plate image is distributed to passing vehicles as an independent "crowdsourced task" through the C-V2X scheduling mechanism of this invention. The onboard ADU (Automatic Vehicle Utility) unit is responsible for running the character recognition function, utilizing the vehicle's idle computing power to perform character recognition on the downloaded license plate sub-images and output the license plate number text.

[0059] 3. Performance Analysis:

[0060] like Figure 5 As shown, this embodiment compares the average processing time of the MEC in two different modes: executing a complete license plate recognition application and executing a license plate detection module. Through the task partitioning and scheduling mechanism of this invention, the single-task computation time of the roadside MEC is reduced by approximately 27.96%.

[0061] like Figure 6 As shown, this embodiment tested license plate images of different sizes in a 5G environment, and statistically analyzed the image size, download time, character recognition time, and total time; the average total time was approximately 140ms, which fully meets the real-time requirements of the license plate recognition task.

[0062] As described above, although the invention has been shown and described with reference to specific preferred embodiments, it should not be construed as limiting the invention itself. Various changes in form and detail may be made without departing from the spirit and scope of the invention as defined in the appended claims.

Claims

1. A C-V2X-based vehicle-mounted mobile crowdsourcing computing platform, characterized in that, It includes a roadside subsystem and an onboard subsystem. The roadside subsystem includes a physically connected roadside unit (RSU) and a mobile edge computing device (MEC). The onboard subsystem includes a physically connected onboard unit (OBU) and an automated driving unit (ADU). Mobile edge computing (MEC) devices are equipped with task partitioning modules and data warehouses, which store task images and function images and are responsible for generating task scheduling instructions. The roadside unit (RSU) is equipped with an RSU-side V2X proxy, which is used to convert the scheduling instructions generated by the MEC into broadcast messages that conform to the C-V2X protocol. The on-board unit (OBU) is equipped with an OBU-side V2X agent, which is used to listen to the C-V2X channel, filter and parse crowdsourced task messages belonging to the vehicle. The autonomous driving unit (ADU) is deployed with the serverless function computing framework OpenFaaS, and manages the lifecycle of function instances through the OpenFaaS gateway; The crowdsourcing calculation method of the above-mentioned vehicle-mounted mobile crowdsourcing computing platform is as follows: Step 1: Task preprocessing and segmentation. The mobile edge computing unit (MEC) acquires the raw task data, segments the large-scale task data into multiple independent sub-tasks, and stores the segmented sub-task data and corresponding computation function images in the repository, generating the corresponding data access address and function image address. Step 2: Control command generation and broadcasting. The Mobile Edge Computing Unit (MEC) sends the data access address, function mirror address, and task parameters to the Roadside Unit (RSU). The V2X proxy module in the RSU encapsulates the above information into a custom C-V2X message frame and broadcasts it to vehicles within the coverage area via C-V2X. Step 3: Task reception and parsing. The on-board unit (OBU) listens for and receives messages broadcast by the RSU through the C-V2X interface, parses out the task metadata, and forwards the task instructions to the autonomous driving unit (ADU) through the on-board internal network. Step 4: Data stream separation transmission and computation. After receiving the instruction, the autonomous driving unit (ADU) pulls the computing environment and the data to be processed through the mobile communication network according to the function mirror address and data access address, and performs the computation task in the local containerized environment. Step 5: Result feedback. After the Autonomous Driving Unit (ADU) completes the calculation, it feeds back the calculation results to the Roadside Unit (RSU) through the Onboard Unit (OBU). The Roadside Unit (RSU) then aggregates the results to the Mobile Edge Computing Unit (MEC) through the proxy module.

2. The C-V2X-based vehicle-mounted mobile crowdsourcing computing platform according to claim 1, characterized in that, The detailed method for task segmentation in step 1 is as follows: Step 1.1, for license plate recognition application scenarios, the original image containing multiple license plates is segmented into independent single license plate image regions; Step 1.2: Decouple the task processing logic into two stages: license plate detection and character recognition; Step 1.3: MEC distributes the segmented single license plate images as subtask units based on the current load.

3. The C-V2X-based vehicle-mounted mobile crowdsourcing computing platform according to claim 1, characterized in that, The custom C-V2X message frame used for communication between the roadside unit (RSU) and the on-board unit (OBU) in step 2 includes a frame header and a message body. The frame header includes a start symbol, protocol version number, vehicle ID, UTC timestamp, message sequence number, and message body length. The message body includes a V2X message header, V2X version number, V2X vehicle ID, V2X timestamp, V2X message ID, V2X message length, V2X message number, V2X message type, and V2X message data.

4. The C-V2X-based vehicle-mounted mobile crowdsourcing computing platform according to claim 1, characterized in that, Both the V2X proxy module of the roadside unit (RSU) and the V2X proxy module of the on-board unit (OBU) include a message listening module and a message distribution module. The proxy captures HTTP requests from internal components (MEC or ADU) by listening to a specific port, parses and reassembles them into V2X messages for transmission; conversely, it restores the received V2X messages into HTTP requests and sends them to the internal components.

Images