# Short-Term Traffic State Prediction Based on Mobile Edge Computing in V2X Communication
## 2 Materials and Methods
### MEC Architecture  
MEC architecture can extend the cloud computing services to the edge of networks according to the white paper proposed by European Telecommunications Standards Institute (ETSI). In our system, edge computing provides a service environment with high bandwidth and low latency in tasks offloading from mobile vehicles to MEC servers. The MEC architecture of this system includes three modules, which are cloud module, roadside module, and on-board module, as described in Figure 3. In this paper, roadside computing resources provided by the MEC architecture can meet the computing demands.  
As shown in Figure 3, the roadside module is the perceptual part of the system, where LiDAR sensors and HD cameras are wired to the MEC server through the switch, and the ICVs are connected with traffic signal controllers based on V2X communications provided by RSU. The cloud module can store the historical traffic data from roadside sensors and provide cloud computing services. The on-board module refers to ICVs with OBUs, which can upload their own messages to the MEC server by task offloading strategy. Specifically, in the MEC architecture, ICVs can receive application-oriented information and upload messages to MEC server via PC5 interface. The service schedule is described in Figure 4.  
In Figure 4, the MEC server is responsible for dealing with the uploaded data of vehicles in the local server, which includes data acquisition and traffic state prediction. The  
Figure 4: The data processing progress of the MEC paradigm.  
Figure 3: MEC architecture.  
MEC server can be integrated into the strategy development of vehicular data acquisition. The process of data acquisition can be described as:  
* Firstly, the MEC server can decide whether the requests of data uploading can be received by listening to messages broadcast from vehicles. These messages include the required bandwidth of the vehicle and the section ID associated with the vehicle.
* The MEC server will check if the ID of the corresponding section is selected. If the ID does not match, the MEC server rejects the request; otherwise, if the ID matches, the actions proceed to the next step.
* The MEC server then checks whether the required bandwidth can be met. If not, the MEC server rejects the request; if yes, the MEC server allocates bandwidth to the vehicle.
* Finally, the MEC server is ready to receive the uploaded vehicle data. If the data is uploaded successfully, the MEC server updates the allocated bandwidth of the corresponding road section. Otherwise, the allocated bandwidth will not be updated.  
As for the traffic state prediction, the MEC server can fuse the actual traffic state based on the uploaded messages of vehicles and multi-source information of roadside sensors. The process can be depicted as:  
* Firstly, multi-source information can be fused by the MEC server.
* Then, the MEC server processes the original vehicular data, including eliminating invalid data and sensing the traffic state information based on vehicular data.
* Finally, by designing a model of short-term traffic state prediction, the MEC server can predict the traffic state of the intersection of the system.