## 3 CTDHR Framework  
In the CTDHR framework, the road is divided into segments with a fixed length, and each segment is called a service domain. There is an RSU deployed in each service domain, and the RSU participates in the transmission of data sent through VANETs. The \begin{table}
\begin{tabular}{c l} \hline \hline
**Acronyms** & \multicolumn{1}{c}{**Definition**} \\ \hline CAVs & connected and automated vehicles \\ IoV & Internet of Vehicles \\ DSRC & dedicated short-range communication \\ C-V2X & cellular vehicle-to-everything \\ VANETs & vehicular ad hoc networks \\ QoS & quality of service \\ CTDHR & cluster-based traffic differentiated hybrid routing \\ TDCR & traffic differentiated clustering routing \\ RSU & roadside unit \\ BS & base station \\ CH & cluster head \\ CM & cluster member \\ \hline \hline \end{tabular}
\end{table} 
Table 1: Acronyms Used in Paper. base station (BS) is used to support the transmission of C-V2X data, and usually one BS can cover multiple service domains. As shown in Figure 1, the vehicles in the service domain are divided into several clusters (the method of cluster division will be shown in Section 4), and a cluster contains one cluster head (CH) and several cluster members (CMs). The CH is the agent for the cluster to communicate with the outside world. When a CM needs to send a data packet, it will first send the data packet to the CH, and then the CH will select DSRC or C-V2X to forward the data to the RSU/BS. In order to reduce the delay caused by intra-cluster communication as much as possible, the distance between the CM and CH in the CTDHR cluster is strictly limited within the DSRC communication radius, which enables the CM and CH to communicate directly without any relay forwarding (i.e., CM and CH are connected in one hop). It is worth noting that each CH needs to establish a VANET communication link with the RSU as much as possible. When the CH of the cluster cannot directly establish communication with the RSU, it can rely on the VANET communication link with other CHs to realize multi-hop communication with the RSU. Therefore, in CTDHR, the communication range of the RSU does not need to cover the entire service domain. In this way, even if there is no VANET link between the two clusters, VANET communication between clusters can be realized through the relay and forwarding of the RSU (of course, each CH establishes a C-V2X link with the BS, so clusters can also rely on C-V2X to achieve inter-cluster communication) [29]. In addition, this cannot only reduce the deployment density of RSUs to reduce infrastructure construction costs, but also make good use of the redundancy of other CH communication capabilities. To complete the above data transmission process, we designed three core algorithms. As shown in Figure 2, all vehicles first report their own statuses (including driving speed, direction, and communication capability) to the edge server. After the data collection is complete, the edge server runs Algorithm 1 (see Algorithm 1 in Section 4) according to the information reported by the vehicle to assign the vehicle to different clusters, and selects the CH for each cluster. Then, according to the clustering results and the communication capabilities of the CHs, Algorithm 2 is run (see Algorithm 2 in Section 4) to obtain the VANET routing path from each CH to the RSU. Finally, the edge server distributes the clustering results and routing path information to the vehicles. At this time, the vehicles  
Figure 1: CTDHR framework. selected, such as CH, will run Algorithm 3 (see Algorithm 3 in Section 4). The main task of Algorithm 3 is to select DSRC/C-V2X according to the current perceived network state to forward the data packets to RSU/BS. Of course, in addition to the need to complete vehicular communication, we also need to consider balancing QoS and user communication costs.