## Appendix A  
Configuration of experiments in the emulator:  
R precomputation produces two main inputs for actual emulation: path loss matrices (used to determine throughput and connectivity) and vehicle movement (location, speed, heading at user-defined time intervals). Three inputs are needed (Figure 9): topology specification, access point locations and specifications, and vehicle waypoints and speed profile.  
Preparations (emulation nodes are illustrated in Figure 12):Copy emulation CSV files (\"ap_data\", \"signal_obs\", and \"vehiclemove\") into mesh nodes (Rainier machines; e.g., router@vehicle).
* Copy \"roles.csv\" into mesh nodes. It contains information about nodes meant to act as AP:s or vehicles in emulation). The format is: \"node\", \"role\" 2, \"AP1\" 4, \"AP2\" 5, \"AP3\" 6, \"AP4\" 7, \"AP5\" 8, \"AP6\" 16, \"V1\" \"node\" number is node ID known by each node. \"role\" is AP or vehicle name used in emulation CSV files.  
Set emulation topology in WMN centralized controller (WCC) configuration file [control center]. The topology determines the links and interfaces of mesh nodes used for vehicle-AP communication.
* In WCC configuration file, the gateway and vehicle nodes must be configured to accept the same combination of IP subnets in user data.
* Ensure, that servers (Edge-node 3, OWAMP-client node) connected to mesh gateway node and vehicle (Router@vehicle) user data ports and the gateway node itself are connected to the network time protocol (NTP) network. The IP addresses of server interfaces to the nodes must belong to a subnet accepted by the gateway and vehicle nodes in WCC configuration.
* Start OWAMP daemon in a server machine (edge node) connected to the gateway node user data port.  
Test stages (see Figure A1):  
1. Send SSH command to emulation nodes [router@vehicle] to start the data and control planes in them. The control plane application \"wmn_control\" check from \"roles.csv\" if the node has an AP or vehicle role in emulation and reads the corresponding data from the CSV files.
* Check from control plane traces [monitored in control center], that all needed links come up in emulation nodes. If not, reboot the node and restart data and control planes.
* Start WCC in a server machine [control center]. WCC sends the mesh configuration to the nodes, which organize according to the configured topology. AP and vehicle nodes receive information from their neighbor emulation nodes.
* Log with SSH to vehicle node [router@vehicle]. Start the ML service front end script \"ml_frontend_redis.py\". It connects to the Redis server [Edge-node 2] and the local control plane.
* Start OWAMP client [OWAMP client] in a server machine [OWAMP-client node] connected to the vehicle node user data port. The ping interval should be the same as the vehicle node ML query interval, e.g., 300 ms with six AP:s. The destination address is the server interface address connected to the gateway user data port. The client dumps the measured delays into a file.  
\[\text{owping -t -c 12000 -i 0.3f -L 10 -R 192.168.200.2 > res.txt}\]
* Start emulation from the WCC command prompt [control center]. Give optionally a number indicating delay (seconds) before emulation start (if omitted, delay is 10 s) Output:The vehicle node [router@vehicle] control plane dumps all delay prediction data received from ML into a CSV file. When it changes route according to the data, it dumps the data into different CSV file. The files have identical format:  
\"time\", \"route\", \"AP1\", \"AP2\", \"AP3\", \"AP4\", \"AP5\", \"AP6\", \"quantity\", and \"vehicle\".  
When the emulation is finished, the results are taken from the OWAMP client output file and vehicle node CSV files into the Influx database measurement tables with Python scripts [Training data store: InfluxDB] [edge node 3]. The OWAMP raw data are put into \"pathquality\" table and the prediction and change dumps into \"route_prediction_6\" and \"route_change_6\" tables, respectively.