## 3 Proposed SDN Simulation Framework  
The proposed SDN simulation framework for smart cities is shown in Figure 1. The framework has three layers: the infrastructure layer, the secure and intelligent SDN layer, and the service layer. The suggested architecture enables diverse networks that include IoT devices, RFID, WSN, ZigBee, sensors, and other network devices. The infrastructure layer includes both the IoT devices and the forwarding devices. The IoT devices, such as RFID, ZigBee, sensors, and WSN, create a variety of IoT applications suitable for smart cities. These wireless devices collect massive volumes of network data, which are then sent to an SDN-based smart city controller for processing. The forwarding devices sublayer consists of MQ telemetry transport (MQTT) gateways, which make it easier for the SDN controller to receive control and data packets. The secure and intelligent SDN layer consists of the global and local SDN controllers. The global SDN controller is responsible for controlling and monitoring communications between the global control center and the IoT application domains. The local SDN controller manages and monitors the communications within an application domain. The service layer makes IoT services possible through the use of SDN controllers. It also provides network services such as routing, security, and quality of service throughout the city. The control plane, which is the low-level details of the configuration and operation of typical network devices such as switches and routers, is traditionally dependent on the operating system of the device in question. This can make it difficult and time-consuming to dynamically reconfigure a network.  
SDN is intended to address this issue, according to the article [23], by the idea of separation of control and data planes, which will allow for software-based device design, as seen in Figure 1. As a result of these principles, a software-based element may be used to operate and configure the network, providing all accompanying benefits, such as dynamic control. Using a logically centralized controller, network performance may be monitored and dynamically adjusted.  
\begin{table}
\begin{tabular}{c c c c c c c} \hline \hline
**Authors** & \begin{tabular}{c} **Detection** \\ **Methodology** \\ \end{tabular} & **SDN** & \begin{tabular}{c} **Machine** \\ **Learning** \\ \end{tabular} & **Test Strategy** & **Attacks Type** & **Dataset** \\ \hline [PERSON] [7] & Entropy-based solution & SDN & No & Experiments & DoS/DDoS & Bot-IoT \\ \hline [PERSON] [8] & Entropy-based solution & SDN & Yes & Simulation & DDoS & UNB ISCX \\ \hline [PERSON] [9] & Anomaly-based & SDx & No & Experiments & DDoS & N/A \\ \hline [PERSON] [10] & Entropy-based solution & SDN & No & Simulation & DDoS & N/A \\ \hline [PERSON] [11]. & CONA & No & No & \
\begin{tabular}{c} NetFPGA- \\ OpenFlow \\ \end{tabular} & DDoS & N/A \\ \hline [PERSON] [12] & Anomaly-based & No & No & OpenFlow & DDoS & N/A \\ \hline [PERSON] [13] & Anomaly-based & No & No & OpenFlow & DDoS & N/A \\ \hline [PERSON] [14] & Anomaly-based & Yes & No & OpenWatch & No & N/A \\ \hline [PERSON] [15] & Anomaly-based & NO & No &
\begin{tabular}{c} IXIA \\ PerfectStorm \\ \end{tabular} & DoS & UNSW-NB15 \\ \hline [PERSON] [17] & Anomaly-based & No & No & Simulation & DDoS & HTTP Botnet \\ \hline [PERSON] [19] & Entropy-based solution & No & No & Simulation & DDoS & CAIDA \\ \hline [PERSON] [20] & Anomaly-based & No & Yes & CICFlowMeter & DDoS & Many \\ \hline \hline \end{tabular}
\end{table}
Table 1: Comparative analysis of existing works.