You are currently viewing a new version of our website. To view the old version click .
Future Internet
  • Article
  • Open Access

8 December 2022

LSSDNF: A Lightweight Secure Software Defined Network Framework for Future Internet in 5G–6G

,
and
1
Computer Science and Engineering Department, Thapar Institute of Engineering & Technology, Patiala 147004, India
2
Power Engineering Department, Faculty of Electrical Engineering Computing and Information Technology, 31000 Osijek, Croatia
*
Authors to whom correspondence should be addressed.
This article belongs to the Special Issue 6G Wireless Communication Systems: Applications, Opportunities and Challenges II

Abstract

As information technology advances quickly, so does the 5G–6G network management system, which is moving toward greater integration, decentralization, diversity, and intelligence. As flexibility is a crucial criterion for 5G–6G network architecture, we use the Software Defined Network (SDN) paradigm to make the programmability more flexible. Due to their ability to replace the current TCP/IP architecture with one that separates the control plane and data plane, software-defined networks have gained much popularity. However, they are susceptible to routing attacks. Therefore, this work proposes Lightweight Security Framework that combines blockchain technology with Software-Defined Networking (LSSDNF) to address this problem. The proposed framework adds the routing data that the controller withheld to the multichain blockchain. Here, a mininet network simulator is used to model the proposed framework. The data transfer rate or network throughput, bandwidth variation, and jitter have all been used to assess the performance of single-controller-SDN networks and multi-controller-SDN networks. The results demonstrate that the proposed framework performs better than the conventional single-controller-SDN architecture in terms of throughput, bandwidth fluctuation, and jitter.

1. Introduction

The 5G/6G network is separated into the 5G/6G network architecture sections: the control layer, the access layer, and the forward layer [1]. This architecture separates user data from the control plane from the user plane only through the access and forwarding layers. In contrast, the control layer performs a logically centralized network control role. The access layer covers a wide range of wireless technologies and network configurations. Based on a common hardware platform, the forward layer can ensure high reliability, minimal delay, and average load of the service data flow.
Blockchain-enhanced Software-Defined Networking refers to a network controlled by a central entity or software used by all the network resources. With an SDN, the control is moved from the network layer to the application layer, dividing the data plane from the control plane. It has numerous advantages over a traditional network, including lower costs, improved security, more flexibility, easier configuration, and prevention of vendor lock-in. A secure framework for SDN can allow a network manager to change the way the network devices, i.e., Routers and Switches, handle packets by enabling complete control of the rules set into network devices from a central console. The mobility of devices in wireless networks has an effect on communication services. The controller can solve position changes in horizontal switching by detecting geographic locations, and it can also somewhat enhance vertical mobility and offer load balancing. Although there is no mobility, the controller can nevertheless locate an alternative route in the event of a failure and balance the traffic between nodes. Some researchers have brought up these issues; however, there are not many workable answers.
Wireless networks have become more virtualized and sophisticated with 5G/6G. While there are significant security flaws in the topology of conventional wireless networks, 5G and 6G promote infrastructure sharing. Even if the widely accepted hypotheses are true, their plausibility is diminished in networks with a large number of adaptive sensing devices. Additionally, the virtualization trend will provide many unknown difficulties.
The variables that affect a network’s quality include bandwidth, Jitter, propagation time, throughput, and latency. One of the most significant is Jitter, which typically causes reduced network throughput and, in certain situations, network congestion that sometimes results in total network failure. The market for Secure-SDN technology is expanding as all the major multinational corporations—including Google, Facebook, and Amazon—adapt to it and change their traditional networks. Traditional networks are now more sluggish, risky, and expensive. Software-Defined Networking with blockchain, on the other hand, enhances network connectivity for sales, customer support, internal communications, and document sharing. This job is in high demand since it integrates blockchain and SDN.
SDN enables complete network control, enabling quick responses to change network or business requirements. By converting them to a Secure Framework for Software Defined Networks, this work focuses on improving the scalability, efficiency, and security of the current Traditional Networks. By dividing the network into three layers—the application layer, control layer, and forwarding layer—traditional decentralized networks converted to centralized SDN networks. These layers each play a part in enhancing the scalability, efficiency, and security of the network. Routing attacks change how packets are routed on the SDN by manipulating routing control information. In order to keep the network secure from routing attacks, the data of the SDN network, such as routing information, including IP addresses and MAC addresses, are stored on a blockchain utilizing multichain.
The contributions of the proposed work are as follows:
This paper first highlights how much faster, more scalable, and less expensive a software-defined network is than a conventional network in 5G–6G SDN.
Building a private blockchain and uploading the network’s routing information makes SDN safe and impossible for anyone to change it. Creation of a private blockchain with the sole purpose of making a network more secure. Therefore, in order to keep the network secure from malicious nodes, the data of the SDN network, such as routing information, including IP addresses and MAC addresses, are stored on a blockchain utilizing multichain.
Transfer rate, jitter, delay, and capacity are among the network performance measures used to evaluate the network in a mininet network simulator.
The remainder of the manuscript is structured as follows: The associated work is briefly reviewed in Section 2. The proposed work is explained in Section 3. The simulation setup and results are presented in Section 4, and Section 5 outlines the conclusions.

3. Proposed Approach

The following discussion covers the many technological ideas connected to the proposed work:
Using software-based controllers or application programming interfaces (APIs) to communicate with the network’s underlying hardware architecture and control traffic is known as software-defined networking (SDN). This architecture is distinct from conventional networks, which manage network traffic using specialized hardware (such as switches and routers). Through software, SDN may build and manage a virtual network or manage conventional hardware. SDN has numerous advantages over traditional or conventional networks because it divides the control plane and the data plane and places the control in the application layer rather than the network layer.
Blockchain data is stored in such a way that system changes, hacking, and cheating is made difficult or impossible. A blockchain is basically a network of nodes that replicates and distributes a digital record of transactions throughout the network. Each blockchain block is made up of numerous transactions, and each individual’s ledger acquires a copy of every new transaction added to the blockchain. The term Distributed Ledger Technology (DLT) refers to a decentralized database maintained by many people. On a blockchain, transactions are stored with an unchangeable cryptographic fingerprint known as a hash. As a result, if a block occurred in only one chain, it would be obvious that it had been updated. To breach a blockchain system, hackers would need to change every block in the chain across all decentralized versions of the chain.
Smart Contracts—A smart contract is a software program that, under specific conditions, controls the exchange of digital wealth between parties directly and autonomously. A smart contract, like any other contract, functions with automated enforcing compliance. Smart contracts are computer programs that run precisely how they are configured (coded, programmed) by their authors. A smart contract is enforceable by code, just way a conventional contract is by law.
iPerf: The maximum possible bandwidth on IP networks can be actively measured using the iPerf. It allows numerous fine-tuning timing, buffer, and protocol-related factors (TCP, UDP, SCTP with IPv4 and IPv6). It provides parameters such as bandwidth, loss, and others for each test.
Multichain—Multichain technology allows users to create specific private blockchains that businesses can utilize for financial transactions. Multichain offers us a command-line interface and a straightforward API. This aids in establishing the chain. The multichain platform cuts the time required for blockchain development by up to 80%.
The steps involved in the proposed smart contract for storing routing information in the multichain are described in Algorithm 1 as follows:
Algorithm 1: Routing Information Registering: MAC Address, IP Address, and Nest Node ID in Multichain
Procedure: Route(list, macAddress, IP, NextNode)
                      Step1: if(device[macAddress]! = True]).
                      Step1.1: then mac_list.push(macAddress).
                      Step1.2: device[macAddress] = True
                      Step2: if(device[IPAddress]! = True]).
                      Step2.1: then ip_list.push(IPAddress).
                      Step2.2: device[IPAddress] = True
                      Step3: if(device[NextNode]! = True]).
                      Step3.1: then NextNode_list.push(NextNode).
                      Step3.2: device[NextNode] = True
                      Step6: end procedure Route
The steps involved in the proposed LSSDNF approach are described in Algorithm 2 as follows:
Algorithm 2: Proposed approach: LSSDNF
The steps involved in the proposed LSSDNF approach are described as follows:
                      Step1: With the aid of the mininet network simulator, the new topology is set up. The topology components are computers, Openflow switches, and an Openflow remote SDN controller.
                      Step2: The Openflow 1.0 protocol is then used to implement the aforementioned architecture in the mininet.
                      Step3: Execute several instances of the cli within the same display when the command-line interface is provided in a window using the Xterm. Use Xterm to access the shells of the two network computers for testing.
                      Step4: Configured one of the two chosen devices as a server and the other as a client using the Iperf utility.
                      Step5: In order to accept incoming packets of the same protocol type, the client creates a TCP or UDP window.
                      Step6: Using the client’s IP address as a connection point, the server begins transmitting data packets to the client.
                      Step7: In addition to receiving the data packets, the client stores each network characteristic in a separate file, such as bandwidth, jitter, and transfer rate.
                      Step8: For each of the two types of topologies, steps 1 through 6 are repeated three times.
                      Step10: Out of the topologies compared above, pick the best one and obtain its routing data from the SDN controller.
                      Step11: Using Multichain, build a private Blockchain and store the routing data.

4. Test System, Assumptions, and Result Analysis

This section provides concrete evidence of how SDN outperforms traditional networks. Here, we tested two distinct network types while controlling the number of devices connected to the network, its bandwidth, and the testing period for each network.

4.1. Simulation Setup

To simulate our network topologies, we used the mininet network emulator. Mininet runs actual kernel, switch, and application code on a single machine to build a realistic virtual network. In this work, we created two topologies using mininet: one with 40 devices, including 30 computers, 9 switches, and 1 SDN controller; the other, with 42 devices, including 30 computers, 9 OpenFlow switches, and 3 SDN controllers.
The multi-controller topology serves only to make the single-controller topology crash-protected. For example, in a single-controller topology, everything depends on the controller, and the entire network will also crash if it crashes. Here, we used a multi-controller topology in a master-slave configuration, where one controller is the master and all the others are slaves; if the master crashes, the slave wakes up and begins acting like the master, and our entire network does not crash.
The following tools and technologies are used to simulate the networks:
Mininet and the Pox SDN controller are used to construct the topology that will be evaluated [30,31].
iPerf is employed in order to test the network [32].
For storing routing information, a multichain private blockchain is used [33].
Smart contracts are created using the Solidity programming language.
For evaluating the behavior of the smart contract under various circumstances, the Mocha testing framework is used.
Ganache-cli for creating a test wallet and blockchain for testing [34].
Truffle HD Wallet Provider for connecting our smart contract to the user’s Metamask wallet in the web3 framework using Remix IDE [34,35].
The parameters used to measure the network performance are given in Table 2, Table 3 and Table 4. The description of the test network is as follows:
Table 2. Parameters used in Single-controller topology.
Table 3. Parameters used in Multi-controller topology.
Table 4. Blockchain Parameters.
In the case of TCP: With a network connection established between the two end devices and a TCP bandwidth restriction of 26 Mbps, data packets were transferred from device 1 to device 2 to test the network.
In the case of UDP: Set the bandwidth restriction to 2 Mbps, and send several UDP data packets from one end device to another end device.
Routing Information—Using the Multichain blockchain development platform, a private blockchain is created and put the routing data (IP, MAC, etc.) to the controller in the multichain.
The test networks with a single-controller and multi-controller topologies are shown in Figure 1 and Figure 2, respectively.
Figure 1. Single-controller SDN Test Network.
Figure 2. Multi-controller SDN Test Network.
Figure 3 and Figure 4 display the state of smart contracts that have been deployed and the cost of transactions on the Ethereum blockchain. The transaction cost in this instance is 589,671 gas, as can be observed. Therefore, creating a private blockchain in the SDN would be economical. With the aid of the Multi-chain blockchain development platform, a private blockchain for network security was created. By uploading our networking routes and controller information to the blockchain, followed by regular checks to see if the network routes have changed or not, the network is made more secure by performing security checks. Therefore, we only need to isolate that one malicious node from the network and avoid performing security checks on the entire network. Here, an attacker tries to provide bogus information to the controller in order to change the routing information. Routing attacks change how packets are routed on SDN by manipulating routing control information [21]. As a result, multi-controller nodes employing multichain can detect a malicious node and an intrusion attempt to change the routing information.
Figure 3. Smart contract deployment.
Figure 4. Transaction cost.

4.2. Simulation Metrics

A description of the test parameters used is provided below:
Bandwidth
Throughput
Latency (Delay)
Jitter
Any network’s performance is determined by the bandwidth and the protocols being utilized. After adjusting some basic variables, including the number of devices in the network, the bandwidth, and the amount of time, the network was tested. The iPerf network tool is used to identify the network characteristics for two distinct types of networks. The aforementioned parameters are applied with the following constraints:
Time: A brief test period of 180 s for each of the three networks was sufficient to produce the desired findings.
Bandwidth: For all three networks, the bandwidth used to extract the TCP and UDP network packet characteristics was set to a constant value of 26 Mbps and 2 Mbps, respectively.
No of Devices: The controller in topology one was the only network device modified. In the first type of architecture, the single-controller topology, we only need a single SDN controller. Specifically, we use three SDN controllers in a master–slave configuration for the multi-controller SDN topology.

4.3. Experimental Results

Traditional TCP Network vs. SDN TCP Network
We evaluated both networks for 180 s while restricting the bandwidth to 25 Mbps and only using TCP protocol packets. Below is a graph of the network properties.
Figure 5 and Figure 6 make it very evident that SDN offers more bandwidth stability than traditional networks.
Figure 5. Traditional Network TCP Bandwidth Fluctuation.
Figure 6. SDN TCP Bandwidth Fluctuation.
Figure 7 clearly shows that throughput nearly stays constant for a constant bandwidth in an SDN network. In contrast, there is so much fluctuation in a traditional network that the transfer rate occasionally drops to zero and stays there for a while. We also noticed that SDN could transfer more data than the conventional network for the same period.
Figure 7. Transfer Rate/Throughput of TCP SDN vs. Traditional Network.

4.4. Traditional UDP Network vs. SDN UDP Network

Both networks are evaluated for 180 s while restricting the bandwidth to 1.05 Mbps and solely using UDP protocol packets. The characteristics of the network are depicted in Figure 8, Figure 9, Figure 10 and Figure 11.
Figure 8. UDP Bandwidth Fluctuation of SDN vs. Traditional Network.
Figure 9. Transfer Rate/Throughput of SDN vs. Traditional Network.
Figure 10. Jitter variation in Traditional Network.
Figure 11. Jitter variation in SDN.
We fixed the bandwidth for the aforementioned tests, but how the network uses the bandwidth is up to it. With SDN, the bandwidth remains constant. SDN, i.e., supplies or provides us with a stable network. However, the traditional network’s bandwidth fluctuates significantly, demonstrating that conventional networks are not stable.
The throughput is shown in the above figure, and as we can see, it is constant for the entire testing period for SDN, but it abruptly drops to zero at 182 s. In contrast, we can see that for Traditional Network, the throughput fluctuates and is not even close to being a constant value. We can also see that it still transfers data after 182 s, i.e., it continues to transfer data even after the testing period has ended. This is concrete evidence that SDN is significantly faster than traditional networks.
According to our testing, the average jitter for SDN networks is 0.112 Mbps, which is a meager value. In contrast, the average jitter for Traditional networks was found to be much higher than the corresponding SDN networks. Jitter is the effect we experience when there is a delay in data transfer in a network. For a network to be good, the jitter should be as low as possible.

4.5. Single-Controller TCP SDN vs. Multi Controller TCP SDN

In this part, we contrast a topology with just one SDN controller with one with several (in this case, three) SDN controllers. This topology has 34 network devices, including 23 computers, 8 OpenFlow switches, and 3 SDN controllers. The single-controller topology has 32 network devices in total, including 23 computers, 8 OpenFlow switches, and one SDN controller. We tested both networks for 180 s while setting the bandwidth to 26.2 Mbps and using TCP protocol packets. The network characteristics are displayed next in Figure 12, Figure 13, Figure 14, Figure 15 and Figure 16.
Figure 12. Bandwidth Fluctuation TCP single-controller SDN vs. TCP Multi-controller SDN.
Figure 13. Transfer Rate/Throughput of TCP single-controller SDN vs. TCP Multi-controller SDN.
Figure 14. UDP bandwidth fluctuation of single-controller SDN vs. Multi-controller SDN.
Figure 15. Transfer rate/Throughput of the UDP single-controller SDN vs. Multi-controller SDN.
Figure 16. Jitter fluctuation single-controller SDN vs. Multi-controller SDN.
Figure 12 shows that both networks’ bandwidth fluctuates in a manner that is essentially the same, with no topology experiencing more significant fluctuations than the others.
Figure 13 shows that both topologies’ data transfer rates are similar and that the multi-controller architecture performs somewhat better than the single-controller topology.

4.6. Single-Controller UDP SDN vs. Multi Controller UDP SDN

In this section, we contrast a topology with a single SDN controller with one with multiple (in this example, three) SDN controllers. In this topology, there are 41 network devices total, including 30 computers, 8 OpenFlow switches, and 3 SDN controllers. In the single-controller topology, there are 39 network devices total, including 30 computers, 8 OpenFlow switches, and one SDN controller. We tested both networks for 180 s while setting the bandwidth to 1.05 Mbps and exclusively using UDP protocol packets.
Figure 14 shows that both topologies—single-controller and multi-controller—show an average fluctuation of 0.01 Mbps, a very negligible fluctuation. As a result, we can conclude that both topologies perform exactly as they should. When compared to the single-controller test network, the multi-controller network performs somewhat better. It follows that a very big network will benefit from the multi-controller’s superior performance.
Figure 15 shows that there is little to no difference in the throughput of the two topologies, indicating that they are both transmitting data at nearly the same pace. This suggests that the two topologies behave at the same pace. Although when compared to the single-controller test network, the multi-controller network performs somewhat better. It follows that a very big network will benefit from the multi-controller’s superior performance.
It is evident from the aforementioned graph that the jitter for both topologies varies, but the average value of jitter for both topologies equals 0.02 Kbps for single-controller SDN and 0.0202 Kbps for multiple controller SDN, which is almost the same. The multi-controller routing information is added to the blockchain. As a result, we can state categorically that multi-controller network topology is superior to a single controller. However, the multi-controller performs better in terms of jitter fluctuation in the event of any breakdown. However, if a single controller quits functioning, the entire network fails.

5. Conclusions

This work presented a Lightweight Secure Framework that blends Software-Defined Networking with blockchain technology. The mininet network simulator is used to model the proposed SDN framework. The data transfer rate or network throughput, bandwidth variation, and jitter have all been used to assess the performance of single-controller-SDN and multi-controller-SDN networks. The results demonstrate that the suggested framework performs better than the conventional single-controller-SDN architecture in terms of throughput, bandwidth fluctuation, and jitter. When three SDN controllers fail in a master-slave configuration in the suggested framework, the multi-controller performs better in terms of bandwidth, transfer rate, and jitter fluctuation. Hence, single points of failure are protected by this dual refrigeration system. If the master controller shuts down for any reason, the following slave controller steps in to act as the master controller until the previous master controller comes back online and begins acting as planned. This ensures that the entire topology is not affected. The network so continues to operate normally as if nothing unexpected had occurred.

Author Contributions

Conceptualization, S.S. and V.M.; methodology, S.S. and V.M.; audit parameters, S.S., V.M., and S.N.; validation, S.S. and V.M.; formal analysis, S.S. and V.M.; investigation, S.S. and V.M.; resources, S.S. and V.M.; writing—original draft preparation, S.S.; writing—review and editing, S.S., V.M., and S.N.; supervision, S.S. and S.N. All authors have read and agreed to the published version of the manuscript.

Funding

This research received no external funding.

Institutional Review Board Statement

Not applicable.

Data Availability Statement

Not applicable.

Acknowledgments

This research was supported by the Thapar Institute of Engineering and Technology, Patiala, under the seed money research project grant scheme with Ref. TU/DORSP/7/2/2022.

Conflicts of Interest

The authors declare that they have no conflicts of interest.

References

  1. Yang, F.Y.; Zhang, J.M.; Xie, W.L.; Wang, M.; Wang, H. Analysis of 5G cellular network architecture. Telecommun. Sci. 2015, 31, 46–56. [Google Scholar]
  2. Akshatha, N.M.; Jha, P.; Karandikar, A. A centralized SDN architecture for the 5G cellular network. In Proceedings of the 2018 IEEE 5G World Forum (5GWF), Silicon Valley, CA, USA, 9–11 July 2018; IEEE: Piscataway, NJ, USA, 2018; pp. 147–152. [Google Scholar]
  3. Long, Q.; Chen, Y.; Zhang, H.; Lei, X. Software defined 5G and 6G networks: A survey. Mob. Netw. Appl. 2022, 27, 1792–1812. [Google Scholar] [CrossRef]
  4. Lv, Z.; Kumar, N. Software defined solutions for sensors in 6G/IoE. Comput. Commun. 2020, 153, 42–47. [Google Scholar] [CrossRef]
  5. Zebari, G.M.; Zebari, D.A.; Al-zebari, A. Fundamentals of 5G cellular networks: A review. J. Inf. Technol. Inform. 2021, 1, 1–5. [Google Scholar]
  6. Yang, T.; Qin, M.; Cheng, N.; Xu, W.; Zhao, L. Liquid software-based edge intelligence for future 6G networks. IEEE Netw. 2022, 36, 69–75. [Google Scholar] [CrossRef]
  7. Yungaicela-Naula, N.M.; Vargas-Rosales, C.; Pérez-Díaz, J.A.; Zareei, M. Towards security automation in software defined networks. Comput. Commun. 2022, 183, 64–82. [Google Scholar] [CrossRef]
  8. Singh, S.; Delia Jurcut, A. (Eds.) Revolutionary Applications of Blockchain-Enabled Privacy and Access Control; IGI Global: Hershey, PA, USA, 2021. [Google Scholar]
  9. Singh, S.; Sharma, R.M. Heuristic based coverage aware load balanced clustering in WSNs and enablement of IoT. Int. J. Inf. Technol. Web Eng. IJITWE 2018, 13, 1–10. [Google Scholar] [CrossRef]
  10. Singh, S.; Mohan Sharma, R. (Eds.) Handbook of Research on the IoT, Cloud Computing, and Wireless Network Optimization; IGI Global: Kurukshetra, India, 2019. [Google Scholar]
  11. Singh, S.; Kumar, P. MH-CACA: Multi-objective harmony search-based coverage aware clustering algorithm in WSNs. Enterp. Inf. Syst. 2020, 14, 1325–1353. [Google Scholar] [CrossRef]
  12. Pokhrel, S.R.; Singh, S. Compound TCP performance for industry 4.0 WiFi: A cognitive federated learning approach. IEEE Trans. Ind. Inform. 2020, 17, 2143–2151. [Google Scholar] [CrossRef]
  13. Mattos, D.M.F.; Duarte, O.C.M.B.; Pujolle, G. A lightweight protocol for consistent policy update on software-defined networking with multiple controllers. J. Netw. Comput. Appl. 2018, 122, 77–87. [Google Scholar] [CrossRef]
  14. Rafique, W.; Qi, L.; Yaqoob, I.; Imran, M.; Rasool, R.U.; Dou, W. Complementing IoT services through software defined networking and edge computing: A comprehensive survey. IEEE Commun. Surv. Tutor. 2020, 22, 1761–1804. [Google Scholar] [CrossRef]
  15. Xue, K.; Meng, W.; Zhou, H.; Wei, D.S.; Guizani, M. A lightweight and secure group key based handover authentication protocol for the software-defined space information network. IEEE Trans. Wirel. Commun. 2020, 19, 3673–3684. [Google Scholar] [CrossRef]
  16. Huo, L.; Jiang, D.; Lv, Z. A software—defined networks—based measurement method of network traffic for 6G technologies. Trans. Emerg. Telecommun. Technol. 2022, 33, e4172. [Google Scholar] [CrossRef]
  17. Abid, M.A.; Afaqui, N.; Khan, M.A.; Akhtar, M.W.; Malik, A.W.; Munir, A.; Ahmad, J.; Shabir, B. Evolution towards smart and software-defined internet of things. AI 2022, 3, 100–123. [Google Scholar] [CrossRef]
  18. Singh, S.; Nikolovski, S.; Chakrabarti, P. GWLBC: Gray Wolf Optimization Based Load Balanced Clustering for Sustainable WSNs in Smart City Environment. Sensors 2022, 22, 7113. [Google Scholar] [CrossRef]
  19. Chica, J.C.C.; Imbachi, J.C.; Vega, J.F.B. Security in SDN: A comprehensive survey. J. Netw. Comput. Appl. 2020, 159, 102595. [Google Scholar] [CrossRef]
  20. Bannour, F.; Souihi, S.; Mellouk, A. Distributed SDN control: Survey, taxonomy, and challenges. IEEE Commun. Surv. Tutor. 2017, 20, 333–354. [Google Scholar] [CrossRef]
  21. Farris, I.; Taleb, T.; Khettab, Y.; Song, J. A survey on emerging SDN and NFV security mechanisms for IoT systems. IEEE Commun. Surv. Tutor. 2018, 21, 812–837. [Google Scholar] [CrossRef]
  22. Javanmardi, S.; Shojafar, M.; Mohammadi, R.; Nazari, A.; Persico, V.; Pescapè, A. FUPE: A security driven task scheduling approach for SDN-based IoT–Fog networks. J. Inf. Secur. Appl. 2021, 60, 102853. [Google Scholar] [CrossRef]
  23. Latif, S.A.; Wen, F.B.X.; Iwendi, C.; Li-li, F.W.; Mohsin, S.M.; Han, Z.; Band, S.S. AI-empowered, blockchain and SDN integrated security architecture for IoT network of cyber physical systems. Comput. Commun. 2022, 181, 274–283. [Google Scholar] [CrossRef]
  24. Daoud, W.B.; Obaidat, M.S.; Meddeb-Makhlouf, A.; Zarai, F.; Hsiao, K.-F. Tacrm: Trust access control and resource management mechanism in fog computing. Hum.-Cent. Comput. Inf. Sci. 2019, 9, 28. [Google Scholar] [CrossRef]
  25. Blanco, B.; Fajardo, J.O.; Giannoulakis, I.; Kafetzakis, E.; Peng, S.; Pérez-Romero, J.; Trajkovska, I.; Khodashenas, P.S.; Goratti, L.; Paolino, M.; et al. Technology pillars in the architecture of future 5G mobile networks: NFV, MEC and SDN. Comput. Stand. Interfaces 2017, 54, 216–228. [Google Scholar] [CrossRef]
  26. Zaidi, Z.; Friderikos, V.; Yousaf, Z.; Fletcher, S.; Dohler, M.; Aghvami, H. Will SDN be part of 5G? IEEE Commun. Surv. Tutor. 2018, 20, 3220–3258. [Google Scholar] [CrossRef]
  27. Barakabitze, A.A.; Ahmad, A.; Mijumbi, R.; Hines, A. 5G network slicing using SDN and NFV: A survey of taxonomy, architectures and future challenges. Comput. Netw. 2020, 167, 106984. [Google Scholar] [CrossRef]
  28. Ashtari, S.; Abdollahi, M.; Abolhasan, M.; Shariati, N.; Lipman, J. Performance analysis of multi-hop routing protocols in SDN-based wireless networks. Comput. Electr. Eng. 2022, 97, 107393. [Google Scholar] [CrossRef]
  29. Persia, S.; Ferranti, L.; Salvo, P.; D’Alterio, F.; Matera, F.; Rea, L.; Lavacca, F.G. Ns3 and Mininet Codes to Investigate Complete 5G Networks. In Proceedings of the 2021 AEIT International Annual Conference (AEIT), Milan, Italy, 4–8 October 2021; IEEE: Piscataway, NJ, USA, 2021; pp. 1–6. [Google Scholar]
  30. Available online: www.mininet.org (accessed on 20 October 2022).
  31. Available online: www.noxrepo.github.io (accessed on 20 October 2022).
  32. Available online: www.iperf.fr (accessed on 20 October 2022).
  33. Available online: www.multichain.com (accessed on 20 October 2022).
  34. Available online: https://truffleframework.com/ganache (accessed on 20 October 2022).
  35. Available online: www.metamask.io (accessed on 20 October 2022).
Publisher’s Note: MDPI stays neutral with regard to jurisdictional claims in published maps and institutional affiliations.

Article Metrics

Citations

Article Access Statistics

Multiple requests from the same IP address are counted as one view.