Software-Defined Networking (SDN) is a significant networking technology that uses programmable interfaces to smoothly link application provisioning in the cloud with the network [1]. This revolution suggests indicators or perhaps different web-based applications. Managers who use massive volumes of data, such as Google and Facebook, are switching to SDN for their fundamental systems ^[2][3][4][2,3,4]. In consideration of layered engineering, the Open Systems Interconnection (OSI) paradigm was implemented in the field of communication. This model approved level-independent advancements and established prohibitive linked issues in heterogeneous frameworks. The major objective of SDN is to revive this theory-based approach to build the organization necessary to contain new settlements and boost creative practices at the same time ^[5][6][7][5,6,7].

SDN is a new paradigm that needs significant advancements in everything from system administration to communication networks. Although there are many different needs for the SDN market, it is apparent that this innovation is an appealing alternative to traditional systems administration and continues to offer useful solutions for inquiry. Currently, wireless technology is taking over the whole world. Currently implemented scenarios predict an increase in demand for SDN-based Wi-Fi. SDN has less support than wireless technologies like Wi-Fi, Wi-MAX 802.16, WLAN 802.11, and Bluetooth 802.15 [5]. Limitations on current applications include the following: On the SDN architecture, there are not many Wi-Fi features accessible. The installation of SDN for end users is not supported by current Wi-Fi networks [7]. Users may construct, configure, alter, and troubleshoot using SDN, which effectively enables programmatic network administration. Thus, it is a significant idea that will shape networks in the future ^[8][10]. The static network designs, or classical architectures, are more difficult than the new ones that are developed programmatically, are overcome by the notion of SDN, making them more flexible and simple to alter and debug ^[9][11]. The work already done on traditional networks cannot adequately address a number of new challenges that the SDN paradigm introduces.

Scalability: In SDN, the issue of complexity and scalability has been brought up. In large data centers, the demand for bandwidth reaches its peak during peak hours. Networks are unable to handle heavy data loads in high-speed traffic flows. Vendors have created their own architectures and specifications for networking devices [6]. Scalability issues can be resolved by laboriously standardizing SDN networking hardware.

Placement of the controller: This is also known as the network operating system, and it is an important aspect for research and discussion in SDN. Whether the position is fixed or dynamic, it needs to be adjusted to the network environment. In controller layout ^[10][12], a number of layout indicators are discussed along with their significance in relation to the surrounding network layout ^[11][12][13,14].

Resilience: The centralized controller architecture comes with a number of built-in restrictions. The main problem with a centralized controller is the single point of failure. Data throughput across the entire network is more efficient thanks to the centralized design ^[13][15]. People might be more open to giving up greater flexibility for greater efficiency. Research on the SDN distributed controller architecture demonstrates that it can offer more flexibility.

SDN controllers, wired networks, Wi-Fi networks, and simulation toolkits used for SDN Wi-Fi networks are all aspects of related study that are being investigated here. On the topic of performance evaluation of wired SDN networks, there are a good number of research articles available:

The effectiveness of floodlight controllers and POX controllers was analyzed and contrasted by Bholebawa et al. ^[14][16]. The authors used Mininet to imitate a variety of topologies and then measured the round-trip time as well as the bandwidth. They came to the conclusion that Floodlight was doing significantly better than POX. POX is recommended in addition to Floodlight because of its usability, notwithstanding the fact that Floodlight achieves good performance.

Performance of “Ryu”, “POX”, and “Pyretic” SDN controllers was analyzed and evaluated by Shamim et al. ^[15][17]. Mininet was the instrument the creators used to recreate a wired SDN. The round-trip time was the most important performance parameter.

Fancy et al. ^[16][18] advise using Floodlight and POX to compare the two systems’ performances. They take into consideration measures such as throughput and delay. Experiments on the controllers have been conducted in a variety of geographical settings. The authors reach the conclusion that Floodlight is effective than POX in terms of its performance. The execution of Floodlight, on the other hand, requires a predetermined quantity of memory space. Because POX is dependent on Python, it is the superior option in this scenario.

In ^[17][19], the authors contrast the performance of the SDN Controllers “Beacon, MuL, Mestro, POX, NOX, Floodlight and Ryu” by making use of the characteristics such as throughput, reliability, safety, and other similar factors. According to the findings of the study, Beacon, NOX, Floodlight, POX, and Ryu are all effective under typical traffic conditions. On the other hand, MuL and Maestro do not appear to be efficient under the same conditions.

Rastogi et al. ^[18][20] examine the similarities and differences between the python-based SDN controllers POX and RYU. Emulation of networks and the production of traffic were both possible with Mininet’s use. The authors concluded that POX offers superior performance when it comes to layer 1 switching. On the other hand, it appears that RYU is superior to POX when it comes to layer 2 exchanging.

There have only been a few studies that have evaluated the performance of “Software defined Wireless networks”.

“Ryu, POX, ONOS, and Floodlight” were tested to see how well they performed in an emulated wireless network by Islam S. and his colleagues ^[9][11]. They evaluated each of these based on jitter and throughput to determine which had the superior performance. It seems that Floodlight has a rather low amount of jitter. The throughput of SDN controllers, on the other hand, does not vary greatly from one to the next.

The authors of the paper ^[19][21] demonstrated the scalability of an SDN-based Wi-Fi Network running on Mininet by analyzing performance characteristics in a variety of different dynamic scenarios. The authors concluded that increasing the number of hosts for the TCP protocol results in a drop in bandwidth and performance, whereas increasing the number of hosts for the UDP protocol has the opposite effect: jitter increases, yet the bandwidth almost entirely maintains its previous level. In wired networks, it would appear that SDN controllers have been thoroughly analyzed in terms of performance. On the other hand, SDWN are a relatively new topic, and large-scale SDN Wi-Fi networks require performance evaluation using a variety of SDN controllers. This can be inferred from an examination of the state of the art.

The study in ^[20][22] proposes an algorithm for efficiently and intelligently changing packet directions in SDN networks. The proposed model estimates path costs based on five criteria: adaptive network packet size, accurate packet numbers, the overall required time interval, QoS link capacity (bandwidth), and the number of hops (shortest path), enabling the SDN controller to minimize decision time for selecting flows. The proposed algorithm is evaluated with a dataset containing information about routing delay. The model incorporates three criteria, namely packet size, number, and time, to determine the optimal packet delay and subsequently calculate the cost of each path. Results from a benchmark comparison between the proposed algorithm and state-of-the-art alternatives show a significant reduction in delay time, estimated to be a few milliseconds, for selecting an optimal recovery path. Consequently, the proposed algorithm can reduce bottleneck routes and resource utilization, leading to increased QoE (Quality of Experience) for both objective and subjective video streaming. Specifically, the proposed model reduces delay time for route selection up to 96.3%, resulting in greater end-user satisfaction.

A software component of SDN known as the SDN controller has the responsibility for managing the flow control of a network. In SDN, the controller is the primary entity that stands among the applications and the networking devices. Each and every communication that takes place between apps and network devices goes through the SDN controller. There are number of SDN controllers; some well-known SDN controllers ^[9][15][17][11,17,19] are shown in Table 1

S.No	Controllers	Platform Support	Programing Languages	Modularity	Centralized/ Distributed	Partner	WI-FI Supported	Open Switch Support	Documentation
1	Floodlight [9][15][17][11,17,19]	Linux	Java	Fair	Centralized	Big Switch Network	No	Yes	Good
2	Ryu [9][15][17][11,17,19]	Linux, Windows and MAC OS	Python	Fair	Centralized	Nippo Telegrah	Yes	Yes	Good
3	Beacon [9][15][17][11,17,19]	Linux, Windows and MAC OS	Java	Fair	Centralized	Stanford University	No	No	Fair
4	POX [9][15][17][11,17,19]	Linux, Windows and MAC OS	Python	Low	Centralized	Nicira	No	No	Poor
5	ONOS [9][15][17][11,17,19]	Linux	Java	High	Distributed	Cisco	No	Yes	Good

The vast majority of the SDN studies that have been proposed in published papers are small-scale Wi-Fi networks that use SDN. However, due to the growing adoption of Wi-Fi networks and the significance of these networks for the Internet of Things, SDN must be integrated with Wi-Fi networks. Integration of Wi-Fi networks with SDN controllers is thought to be able to overcome a significant number of performance difficulties that are associated with Wi-Fi networks. For this reason, a performance analysis of an actual large-scale SDN Wi-Fi network is necessary for upcoming Internet of things networks ^[8][10]. SDN was initially created for wired networks; however, wireless networks can also benefit from its principles. In order to manage and control the access points and switches that make up a WiFi network, many SDN controllers, including Ryu, support Wi-Fi networks. There are several well-known SDN controllers with varying degrees of Wi-Fi network support, including Ryu, Floodlight, Beacon, POX, and ONOS. Ryu has a solid track record of supporting Wi-Fi networks and offering a wide range of protocol support, including OpenFlow and Netconf, which are frequently used in Wi-Fi networks. Floodlight is suitable for managing Wi-Fi networks because it, like Ryu, supports OpenFlow and Netconf. However, Floodlight’s focus is more on large-scale data center networks, which may not be the primary use case for Wi-Fi networks. On the other hand, Beacon is a research-focused SDN controller that is not frequently used in real-world environments. Although it manages Wi-Fi networks and supports OpenFlow, it might not offer Ryu’s level of performance, scalability, and reliability. Similar to this, POX is a compact SDN controller that is frequently employed in academic and research settings. While it can be used to manage Wi-Fi networks, Ryu’s more powerful controllers have more functionality and scalability ^[21][22][23][23,24,25].