├── figures ├── 2d.png ├── 3d.png ├── arch.png ├── dhcp.png ├── freq.png ├── info.png ├── loop.png ├── lupa.png ├── qos.png ├── req.png ├── ssid.png ├── sumo.png ├── vlan.png ├── vnd.png ├── adhoc.png ├── alert.png ├── excla.png ├── infra.png ├── lowpan.png ├── mptcp.png ├── radius.png ├── video.png ├── wpan1.png ├── xterm.png ├── aircrack.png ├── arpspoof.png ├── bonding.png ├── fading-en.png ├── freq-en.png ├── handover.png ├── internet.png ├── linssid.png ├── linssid2.png ├── miniedit.png ├── physical.png ├── ping_of.png ├── question.png ├── sdwn-en.png ├── sflow-rt.png ├── snort-h1.png ├── topo-vlan.png ├── topo-wifi.png ├── wallpaper.png ├── adhoc-mesh.png ├── background.pdf ├── basic-wifi.png ├── bssid-based.png ├── components.png ├── p4-handover.png ├── placeholder.jpg ├── radius-topo.png ├── topo-linear.png ├── topo-single.png ├── usb-dongle.jpg ├── xterm-test.png ├── graph-mobility.png ├── ping-wireshark.png ├── telemetry-rssi.png ├── topo-rot-dina.png ├── frame-header-en.png ├── related-work-en.png ├── wifi-padroes-en.png ├── 802-11-b-channels.jpg ├── chapter_head_2_bkp.png ├── propagationRSSI-en.png ├── topo-rot-estatico.png ├── wireshark-beacons.png ├── wireshark-interface.png ├── wireshark-ofproto.png └── beacon-wireshark-controller.png ├── README.md ├── toc.md ├── background.md └── beginner.md /figures/2d.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ramonfontes/mn-wifi-ebook/HEAD/figures/2d.png -------------------------------------------------------------------------------- /figures/3d.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ramonfontes/mn-wifi-ebook/HEAD/figures/3d.png -------------------------------------------------------------------------------- /figures/arch.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ramonfontes/mn-wifi-ebook/HEAD/figures/arch.png -------------------------------------------------------------------------------- /figures/dhcp.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ramonfontes/mn-wifi-ebook/HEAD/figures/dhcp.png -------------------------------------------------------------------------------- /figures/freq.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ramonfontes/mn-wifi-ebook/HEAD/figures/freq.png -------------------------------------------------------------------------------- /figures/info.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ramonfontes/mn-wifi-ebook/HEAD/figures/info.png -------------------------------------------------------------------------------- /figures/loop.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ramonfontes/mn-wifi-ebook/HEAD/figures/loop.png -------------------------------------------------------------------------------- /figures/lupa.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ramonfontes/mn-wifi-ebook/HEAD/figures/lupa.png -------------------------------------------------------------------------------- /figures/qos.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ramonfontes/mn-wifi-ebook/HEAD/figures/qos.png -------------------------------------------------------------------------------- /figures/req.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ramonfontes/mn-wifi-ebook/HEAD/figures/req.png -------------------------------------------------------------------------------- /figures/ssid.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ramonfontes/mn-wifi-ebook/HEAD/figures/ssid.png -------------------------------------------------------------------------------- /figures/sumo.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ramonfontes/mn-wifi-ebook/HEAD/figures/sumo.png -------------------------------------------------------------------------------- /figures/vlan.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ramonfontes/mn-wifi-ebook/HEAD/figures/vlan.png -------------------------------------------------------------------------------- /figures/vnd.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ramonfontes/mn-wifi-ebook/HEAD/figures/vnd.png -------------------------------------------------------------------------------- /figures/adhoc.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ramonfontes/mn-wifi-ebook/HEAD/figures/adhoc.png -------------------------------------------------------------------------------- /figures/alert.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ramonfontes/mn-wifi-ebook/HEAD/figures/alert.png -------------------------------------------------------------------------------- /figures/excla.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ramonfontes/mn-wifi-ebook/HEAD/figures/excla.png -------------------------------------------------------------------------------- /figures/infra.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ramonfontes/mn-wifi-ebook/HEAD/figures/infra.png -------------------------------------------------------------------------------- /figures/lowpan.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ramonfontes/mn-wifi-ebook/HEAD/figures/lowpan.png -------------------------------------------------------------------------------- /figures/mptcp.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ramonfontes/mn-wifi-ebook/HEAD/figures/mptcp.png -------------------------------------------------------------------------------- /figures/radius.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ramonfontes/mn-wifi-ebook/HEAD/figures/radius.png -------------------------------------------------------------------------------- /figures/video.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ramonfontes/mn-wifi-ebook/HEAD/figures/video.png -------------------------------------------------------------------------------- /figures/wpan1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ramonfontes/mn-wifi-ebook/HEAD/figures/wpan1.png -------------------------------------------------------------------------------- /figures/xterm.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ramonfontes/mn-wifi-ebook/HEAD/figures/xterm.png -------------------------------------------------------------------------------- /figures/aircrack.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ramonfontes/mn-wifi-ebook/HEAD/figures/aircrack.png -------------------------------------------------------------------------------- /figures/arpspoof.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ramonfontes/mn-wifi-ebook/HEAD/figures/arpspoof.png -------------------------------------------------------------------------------- /figures/bonding.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ramonfontes/mn-wifi-ebook/HEAD/figures/bonding.png -------------------------------------------------------------------------------- /figures/fading-en.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ramonfontes/mn-wifi-ebook/HEAD/figures/fading-en.png -------------------------------------------------------------------------------- /figures/freq-en.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ramonfontes/mn-wifi-ebook/HEAD/figures/freq-en.png -------------------------------------------------------------------------------- /figures/handover.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ramonfontes/mn-wifi-ebook/HEAD/figures/handover.png -------------------------------------------------------------------------------- /figures/internet.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ramonfontes/mn-wifi-ebook/HEAD/figures/internet.png -------------------------------------------------------------------------------- /figures/linssid.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ramonfontes/mn-wifi-ebook/HEAD/figures/linssid.png -------------------------------------------------------------------------------- /figures/linssid2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ramonfontes/mn-wifi-ebook/HEAD/figures/linssid2.png -------------------------------------------------------------------------------- /figures/miniedit.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ramonfontes/mn-wifi-ebook/HEAD/figures/miniedit.png -------------------------------------------------------------------------------- /figures/physical.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ramonfontes/mn-wifi-ebook/HEAD/figures/physical.png -------------------------------------------------------------------------------- /figures/ping_of.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ramonfontes/mn-wifi-ebook/HEAD/figures/ping_of.png -------------------------------------------------------------------------------- /figures/question.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ramonfontes/mn-wifi-ebook/HEAD/figures/question.png -------------------------------------------------------------------------------- /figures/sdwn-en.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ramonfontes/mn-wifi-ebook/HEAD/figures/sdwn-en.png -------------------------------------------------------------------------------- /figures/sflow-rt.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ramonfontes/mn-wifi-ebook/HEAD/figures/sflow-rt.png -------------------------------------------------------------------------------- /figures/snort-h1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ramonfontes/mn-wifi-ebook/HEAD/figures/snort-h1.png -------------------------------------------------------------------------------- /figures/topo-vlan.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ramonfontes/mn-wifi-ebook/HEAD/figures/topo-vlan.png -------------------------------------------------------------------------------- /figures/topo-wifi.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ramonfontes/mn-wifi-ebook/HEAD/figures/topo-wifi.png -------------------------------------------------------------------------------- /figures/wallpaper.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ramonfontes/mn-wifi-ebook/HEAD/figures/wallpaper.png -------------------------------------------------------------------------------- /figures/adhoc-mesh.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ramonfontes/mn-wifi-ebook/HEAD/figures/adhoc-mesh.png -------------------------------------------------------------------------------- /figures/background.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ramonfontes/mn-wifi-ebook/HEAD/figures/background.pdf -------------------------------------------------------------------------------- /figures/basic-wifi.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ramonfontes/mn-wifi-ebook/HEAD/figures/basic-wifi.png -------------------------------------------------------------------------------- /figures/bssid-based.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ramonfontes/mn-wifi-ebook/HEAD/figures/bssid-based.png -------------------------------------------------------------------------------- /figures/components.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ramonfontes/mn-wifi-ebook/HEAD/figures/components.png -------------------------------------------------------------------------------- /figures/p4-handover.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ramonfontes/mn-wifi-ebook/HEAD/figures/p4-handover.png -------------------------------------------------------------------------------- /figures/placeholder.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ramonfontes/mn-wifi-ebook/HEAD/figures/placeholder.jpg -------------------------------------------------------------------------------- /figures/radius-topo.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ramonfontes/mn-wifi-ebook/HEAD/figures/radius-topo.png -------------------------------------------------------------------------------- /figures/topo-linear.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ramonfontes/mn-wifi-ebook/HEAD/figures/topo-linear.png -------------------------------------------------------------------------------- /figures/topo-single.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ramonfontes/mn-wifi-ebook/HEAD/figures/topo-single.png -------------------------------------------------------------------------------- /figures/usb-dongle.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ramonfontes/mn-wifi-ebook/HEAD/figures/usb-dongle.jpg -------------------------------------------------------------------------------- /figures/xterm-test.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ramonfontes/mn-wifi-ebook/HEAD/figures/xterm-test.png -------------------------------------------------------------------------------- /figures/graph-mobility.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ramonfontes/mn-wifi-ebook/HEAD/figures/graph-mobility.png -------------------------------------------------------------------------------- /figures/ping-wireshark.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ramonfontes/mn-wifi-ebook/HEAD/figures/ping-wireshark.png -------------------------------------------------------------------------------- /figures/telemetry-rssi.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ramonfontes/mn-wifi-ebook/HEAD/figures/telemetry-rssi.png -------------------------------------------------------------------------------- /figures/topo-rot-dina.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ramonfontes/mn-wifi-ebook/HEAD/figures/topo-rot-dina.png -------------------------------------------------------------------------------- /figures/frame-header-en.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ramonfontes/mn-wifi-ebook/HEAD/figures/frame-header-en.png -------------------------------------------------------------------------------- /figures/related-work-en.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ramonfontes/mn-wifi-ebook/HEAD/figures/related-work-en.png -------------------------------------------------------------------------------- /figures/wifi-padroes-en.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ramonfontes/mn-wifi-ebook/HEAD/figures/wifi-padroes-en.png -------------------------------------------------------------------------------- /figures/802-11-b-channels.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ramonfontes/mn-wifi-ebook/HEAD/figures/802-11-b-channels.jpg -------------------------------------------------------------------------------- /figures/chapter_head_2_bkp.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ramonfontes/mn-wifi-ebook/HEAD/figures/chapter_head_2_bkp.png -------------------------------------------------------------------------------- /figures/propagationRSSI-en.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ramonfontes/mn-wifi-ebook/HEAD/figures/propagationRSSI-en.png -------------------------------------------------------------------------------- /figures/topo-rot-estatico.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ramonfontes/mn-wifi-ebook/HEAD/figures/topo-rot-estatico.png -------------------------------------------------------------------------------- /figures/wireshark-beacons.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ramonfontes/mn-wifi-ebook/HEAD/figures/wireshark-beacons.png -------------------------------------------------------------------------------- /figures/wireshark-interface.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ramonfontes/mn-wifi-ebook/HEAD/figures/wireshark-interface.png -------------------------------------------------------------------------------- /figures/wireshark-ofproto.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ramonfontes/mn-wifi-ebook/HEAD/figures/wireshark-ofproto.png -------------------------------------------------------------------------------- /figures/beacon-wireshark-controller.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ramonfontes/mn-wifi-ebook/HEAD/figures/beacon-wireshark-controller.png -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | The Mininet-WiFi book is now free and open, and you can contribute! 2 | 3 | You can still have a printed version (_en_ and _pt_ editions) if you prefer. Visit https://mininet-wifi.github.io/book/ for more details. 4 | 5 | # Chapter Organization 6 | 7 | This book is organized as follows: 8 | 9 | [**Chapter I**](https://github.com/ramonfontes/mn-wifi-ebook/blob/main/background.md) introduces theoretical fundamentals of wireless networks, software-defined wireless networks and also Mininet-WiFi. This chapter goes in-depth 10 | into concepts relevant to the learning objectives of this book. For a deeper understanding of the different topics explored, the reader will be provided 11 | references to relevant literature in the field; 12 | 13 | [**Chapter II**](https://github.com/ramonfontes/mn-wifi-ebook/blob/main/beginner.md) introduces the beginner level of Mininet-WiFi proficiency and is devoted solely to providing the working details of Mininet-WiFi, where 14 | its key functional aspects are described. If you are already proficient with Mininet-WiFi, you can focus on chapters III and IV instead. You do not need 15 | to be familiar with Mininet to use Mininet-WiFi, but if you are, you will certainly have a smoother feel as to how Mininet-WiFi works. The tutorials 16 | included in this chapter can be used as complementary activities in theory classes at the undergraduate level (e.g. EA074 at FEEC/UNICAMP), as well 17 | as in practical laboratory courses (e.g. EA080 at FEEC/UNICAMP); 18 | 19 | [**Chapter III**](https://github.com/ramonfontes/mn-wifi-ebook/blob/main/intermediate.md) introduces the intermediate level of Mininet-WiFi proficiency, covers tutorials that employ wireless networking, software-defined wireless 20 | networking, as well as a number of concepts related to computer networking. This chapter also describes the use of some network applications, such as 21 | tcpdump and Wireshark. In addition to meeting the pedagogical goals of more advanced computer network classes such as those involving laboratory 22 | activities, the tutorials in this chapter are also suitable for graduat classes(e.g. IA369, IA376 at FEEC/UNICAMP) and specialization courses (e.g. 23 | INF-556 at IC/UNICAMP), as they allow experimental research to be carried in more complex scenarios, such as the development of SDN solutions using 24 | the OpenFlow protocol; 25 | 26 | Finally, [**Chapter IV**](https://github.com/ramonfontes/mn-wifi-ebook/blob/main/expert.md) introduces the expert level of Mininet-WiFi proficiency, has tutorials about kernel manipulation, containers, security, IoT, vehicular 27 | networks, etc., with valuable information on adapting the OpenFlow protocol to wireless networks. This chapter is labeled as advanced because it requiresmore in-depth knowledge and the use of third-party applications. Therefore, 28 | the tutorials in this chapter are best suited for specialization and graduate courses, not only in classes but also as technical training for master’s and doc- 29 | toral students, thus helping the development of experimental research aimed at advancing the state of the art. However, nothing prevents curious readers from 30 | reproducing these tutorials, since they have similar walkthroughs, as well as the support provided by the codes from the previous chapters. 31 | 32 | 33 | # Precautions 34 | It is recommended that all tutorials available in this book be completed using the latest version of Mininet-WiFi available on Github. Should you, the reader, 35 | find any inconsistencies in the tutorials, you may contact the authors of this book at any time for clarification. 36 | Although this book brings hands-on experience at all times, we recommend that you review each command or configuration beforehand so that the entire 37 | process can be understood. Do not try to complete the tutorials without clearly understanding what is being done! 38 | 39 | ## I must use Linux. But why? 40 | Because the code base of Mininet-WiFi, Mininet, was developed for Linux systems. The development of Mininet-WiFi has maintained the same operating 41 | structure as that of Mininet. The Ubuntu operating system should be preferred, especially its Long Term Support (LTS) versions, as they are the most stable 42 | Ubuntu distributions. 43 | 44 | ## Why open source code? 45 | We will answer this question with a simple answer: because most of the time we (you, I and everyone) have the freedom to use the tool/program we want. 46 | Whether it is because we need to do work or academic research, or because we want to know more about Mininet-WiFi, or even because we need to modify it 47 | to suit our needs, we can choose. However, this seems like a ready answer, which we often receive as an answer by others when we wonder about the 48 | advantages of opening the source code of a particular program. Arguing chronologically, we could say that without Mininet-WiFi, I, Ra- 49 | mon, would not have obtained a doctoral degree; many researchers would not have done their research; Mininet, the emulator Mininet-WiFi was based on, 50 | would probably not exist either, and so on. What we mean is that without open source philosophy, we would not have access to Mininet and would not have 51 | developed Mininet-WiFi. Just as Mininet would not have been developed with-out the previous development of its backbone and its subsequent availability 52 | for anyone to use. Most likely you would not even be reading this book now and many fewer persons would be interested in the subjects we covered in it. 53 | Can you imagine how much research on other topics would be undermined by only focusing on the field of research covered in this book and ignoring other 54 | possibilities? Perhaps you will have a better idea as you complete the tutorials proposed throughout this book. 55 | There is a whole chain that would be seriously impacted if the codes were not free to use. The main paper [14] about Mininet alone has had about 1500 56 | direct citations, not to mention countless indirect citations by blogs and even 57 | the media. 58 | 59 | ## Experiences: Impact, Reproducibility and Quality 60 | If you are wondering whether it is worth researching and exposing your code to the public, even though it is still in the early stages of development, here 61 | are some reports of experiences we have gained throughout Mininet-WiFi development. 62 | 63 | **Impact**. Making code, data, documentation and demonstration videos public has certainly contributed and still greatly contributes to increasing Mininet- 64 | WiFi’s visibility. Although there has been no systematic and qualitative assessment of the Mininet-WiFi community, users have contributed to the project 65 | several times, whether by discussing or even suggesting code improvements and new implementations. 66 | 67 | **Reproducibility**. Making data public and reproducible is not always a simple task. By the way, writing a book whose tutorials users can complete without 68 | any setbacks is not easy. Most likely there will be one or another tutorial that will not flow as expected. This is due to several factors, such as differences in 69 | tool versions, issues that may be related to the operating system, hardware, etc. Throughout the development of Mininet-WiFi, we had a hard time reproducing 70 | experiments by other researchers, as there was often not enough information to do so. For this reason, we have chosen not only to make our experimentspublic, but also to describe how they can be reproduced. Making research 71 | reproducible generally adds credibility to its respective work and obtained results. 72 | 73 | **Quality**. In a broader sense of research quality, all the experiences gained throughout the development of Mininet-WiFi allowed us to learn and refine 74 | our research. Although ensuring the reproducibility of a project increases workload, reproducible work has a number of significant advantages, such as: 75 | (i) synergy with open source functionality, as the latter increases the chances of direct and indirect reproducibility and, consequently, (ii) greater impact, since 76 | the chances of researchers using the solutions proposed by reproducible works increase; (iii) improvement of programming habits, wherein special attention 77 | is given to code quality; (iv) encouragement of the use of scientific workflows, as researchers are carefully concerned with providing reliable results so that 78 | anyone can produce results similar to those they have obtained. So if you have the opportunity, and if your code is not a license, patent, or any other copyrighted content, try making your code public! 79 | 80 | 81 | # Authors 82 | Ramon dos Reis Fontes (ramon.fontes@imd.ufrn.br) 83 | Christian Rodolfo Esteve Rothenberg (chesteve@dca.fee.unicamp.br) -------------------------------------------------------------------------------- /toc.md: -------------------------------------------------------------------------------- 1 | **Table of Contents**: 2 | 3 | [**Background**](https://github.com/ramonfontes/mn-wifi-ebook/blob/main/background.md) 4 | - [Wireless communications](https://github.com/ramonfontes/mn-wifi-ebook/blob/main/background.md#wireless-communications) 5 | - [WiFi: IEEE 802.11-based wireless local area networks](https://github.com/ramonfontes/mn-wifi-ebook/blob/main/background.md#wifi-ieee-80211-based-wireless-local-area-networks) 6 | - [Software-defined wireless networking](https://github.com/ramonfontes/mn-wifi-ebook/blob/main/background.md#software-defined-wireless-networking) 7 | - [Mininet-WiFi](https://github.com/ramonfontes/mn-wifi-ebook/blob/main/background.md#mininet-wifi) 8 | - [Architecture](https://github.com/ramonfontes/mn-wifi-ebook/blob/main/background.md#architecture) 9 | - [Components](https://github.com/ramonfontes/mn-wifi-ebook/blob/main/background.md#components) 10 | 11 | [**Beginner**](https://github.com/ramonfontes/mn-wifi-ebook/blob/main/beginner.md) 12 | - [Downloading and installing Mininet-WiFi](https://github.com/ramonfontes/mn-wifi-ebook/blob/main/beginner.md#downloading-and-installing-mininet-wifi) 13 | - [First steps to use Mininet-WiFi](https://github.com/ramonfontes/mn-wifi-ebook/blob/main/beginner.md#first-steps-to-use-mininet-wifi) 14 | - [Customizing topologies](https://github.com/ramonfontes/mn-wifi-ebook/blob/main/beginner.md#customizing-topologies) 15 | - [Accessing node information](https://github.com/ramonfontes/mn-wifi-ebook/blob/main/beginner.md#accessing-node-information) 16 | - [OVSAP versus UserAP](https://github.com/ramonfontes/mn-wifi-ebook/blob/main/beginner.md#ovsap-versus-userap) 17 | - [Graphical User Interface (GUI)](https://github.com/ramonfontes/mn-wifi-ebook/blob/main/beginner.md#graphical-user-interface-gui) 18 | - [Visual Network Descriptor](https://github.com/ramonfontes/mn-wifi-ebook/blob/main/beginner.md#visual-network-descriptor) 19 | - [MiniEdit](https://github.com/ramonfontes/mn-wifi-ebook/blob/main/beginner.md#miniedit) 20 | - [Viewing 2D and 3D graphics](https://github.com/ramonfontes/mn-wifi-ebook/blob/main/beginner.md#viewing-2d-and-3d-graphics) 21 | - [Wireless network emulation](https://github.com/ramonfontes/mn-wifi-ebook/blob/main/beginner.md#wireless-network-emulation) 22 | - [TC (Traffic Control)](https://github.com/ramonfontes/mn-wifi-ebook/blob/main/beginner.md#tc-traffic-control) 23 | - [Wmediumd](https://github.com/ramonfontes/mn-wifi-ebook/blob/main/beginner.md#wmediumd) 24 | - [TC versus Wmediumd in practice](https://github.com/ramonfontes/mn-wifi-ebook/blob/main/beginner.md#tc-_versus-wmediumd-in-practice) 25 | - [Propagation model](https://github.com/ramonfontes/mn-wifi-ebook/blob/main/beginner.md#propagation-model) 26 | - [Providing more realism](https://github.com/ramonfontes/mn-wifi-ebook/blob/main/beginner.md#providing-more-realism) 27 | - [Distance versus received signal](https://github.com/ramonfontes/mn-wifi-ebook/blob/main/beginner.md#distance-versus-received-signal) 28 | - [Modifying bitrate](https://github.com/ramonfontes/mn-wifi-ebook/blob/main/beginner.md#modifying-bitrate) 29 | - [Distance versus throughput](https://github.com/ramonfontes/mn-wifi-ebook/blob/main/beginner.md#distance-versus-throughput) 30 | - [Mobility models](https://github.com/ramonfontes/mn-wifi-ebook/blob/main/beginner.md#mobility-models) 31 | 32 | [**Intermediate**](https://github.com/ramonfontes/mn-wifi-ebook/blob/main/intermediate.md#intermediate) 33 | - [Network interfaces](https://github.com/ramonfontes/mn-wifi-ebook/blob/main/intermediate.md#network-interfaces) 34 | - [Setting multiple interfaces](https://github.com/ramonfontes/mn-wifi-ebook/blob/main/intermediate.md#setting-multiple-interfaces) 35 | - [Binding interfaces](https://github.com/ramonfontes/mn-wifi-ebook/blob/main/intermediate.md#binding-interfaces) 36 | - [Bonding interfaces](https://github.com/ramonfontes/mn-wifi-ebook/blob/main/intermediate.md#bonding-interfaces) 37 | - [Traffic analysis](https://github.com/ramonfontes/mn-wifi-ebook/blob/main/intermediate.md#traffic-analysis) 38 | - [Capturing packets](https://github.com/ramonfontes/mn-wifi-ebook/blob/main/intermediate.md#capturing-packets) 39 | - [Capturing beacons](https://github.com/ramonfontes/mn-wifi-ebook/blob/main/intermediate.md#capturing-beacons) 40 | - [Spectrum analysis](https://github.com/ramonfontes/mn-wifi-ebook/blob/main/intermediate.md#spectrum-analysis) 41 | - [Network telemetry](https://github.com/ramonfontes/mn-wifi-ebook/blob/main/intermediate.md#network-telemetry) 42 | - [Scanning methods](https://github.com/ramonfontes/mn-wifi-ebook/blob/main/intermediate.md#scanning-methods) 43 | - [Active scanning](https://github.com/ramonfontes/mn-wifi-ebook/blob/main/intermediate.md#active-scanning) 44 | - [Passive scanning](https://github.com/ramonfontes/mn-wifi-ebook/blob/main/intermediate.md#passive-scanning) 45 | - [Wireless mesh and ad hoc](https://github.com/ramonfontes/mn-wifi-ebook/blob/main/intermediate.md#wireless-mesh-and-ad-hoc) 46 | - [OpenFlow protocol](https://github.com/ramonfontes/mn-wifi-ebook/blob/main/intermediate.md#openflow-protocol) 47 | - [Capturing OpenFlow messages](https://github.com/ramonfontes/mn-wifi-ebook/blob/main/intermediate.md#capturing-openflow-messages) 48 | - [Creating flows](https://github.com/ramonfontes/mn-wifi-ebook/blob/main/intermediate.md#creating-flows) 49 | - [OpenFlow and wireless networks](https://github.com/ramonfontes/mn-wifi-ebook/blob/main/intermediate.md#openflow-and-wireless-networks) 50 | - [Remote controller](https://github.com/ramonfontes/mn-wifi-ebook/blob/main/intermediate.md#remote-controller) 51 | - [OpenFlow and handover](https://github.com/ramonfontes/mn-wifi-ebook/blob/main/intermediate.md#openflow-and-handover) 52 | - [Use case scenarios](https://github.com/ramonfontes/mn-wifi-ebook/blob/main/intermediate.md#use-case-scenarios) 53 | - [WEB server](https://github.com/ramonfontes/mn-wifi-ebook/blob/main/intermediate.md#web-server) 54 | - [DHCP server](https://github.com/ramonfontes/mn-wifi-ebook/blob/main/intermediate.md#dhcp-server) 55 | - [Dealing with loops](https://github.com/ramonfontes/mn-wifi-ebook/blob/main/intermediate.md#dealing-with-loops) 56 | - [Virtual LAN (VLAN)](https://github.com/ramonfontes/mn-wifi-ebook/blob/main/intermediate.md#virtual-lan-vlan) 57 | - [Routing](https://github.com/ramonfontes/mn-wifi-ebook/blob/main/intermediate.md#routing) 58 | - [Firewall](https://github.com/ramonfontes/mn-wifi-ebook/blob/main/intermediate.md#firewall) 59 | - [Quality of Service (QoS)](https://github.com/ramonfontes/mn-wifi-ebook/blob/main/intermediate.md#quality-of-service-qos) 60 | - [MultiPath TCP (MP-TCP)](https://github.com/ramonfontes/mn-wifi-ebook/blob/main/intermediate.md#multipath-tcp-mp-tcp) 61 | - [Extras](https://github.com/ramonfontes/mn-wifi-ebook/blob/main/intermediate.md#extras) 62 | - [GRE Tunnel](https://github.com/ramonfontes/mn-wifi-ebook/blob/main/intermediate.md#gre-tunnel) 63 | - [6in4](https://github.com/ramonfontes/mn-wifi-ebook/blob/main/intermediate.md#6in4) 64 | 65 | [**Expert**](https://github.com/ramonfontes/mn-wifi-ebook/blob/main/expert.md) 66 | - [Manipulating kernel modules](https://github.com/ramonfontes/mn-wifi-ebook/blob/main/expert.md#manipulating-kernel-modules) 67 | - [Traffic monitoring with sFlow-RT](https://github.com/ramonfontes/mn-wifi-ebook/blob/main/expert.md#traffic-monitoring-with-sflow-rt) 68 | - [Reproducing network behavior](https://github.com/ramonfontes/mn-wifi-ebook/blob/main/expert.md#reproducing-network-behavior) 69 | - [Network attributes](https://github.com/ramonfontes/mn-wifi-ebook/blob/main/expert.md#network-attributes) 70 | - [Mobility](https://github.com/ramonfontes/mn-wifi-ebook/blob/main/expert.md#mobility) 71 | - [Socket - low-level networking interface](https://github.com/ramonfontes/mn-wifi-ebook/blob/main/expert.md#socket---low-level-networking-interface) 72 | - [P4](https://github.com/ramonfontes/mn-wifi-ebook/blob/main/expert.md#p4) 73 | - [Differences between P4 and OpenFlow](https://github.com/ramonfontes/mn-wifi-ebook/blob/main/expert.md#differences-between-p4-and-openflow) 74 | - [Basic WiFi scenario](https://github.com/ramonfontes/mn-wifi-ebook/blob/main/expert.md#basic-wifi-scenario) 75 | - [Handover](https://github.com/ramonfontes/mn-wifi-ebook/blob/main/expert.md#handover) 76 | - [Dropping packets based on BSSID](https://github.com/ramonfontes/mn-wifi-ebook/blob/main/expert.md#dropping-packets-based-on-bssid) 77 | - [Use case scenarios](https://github.com/ramonfontes/mn-wifi-ebook/blob/main/expert.md#use-case-scenarios) 78 | - [Containers](https://github.com/ramonfontes/mn-wifi-ebook/blob/main/expert.md#containers) 79 | - [Interaction between virtual and real environments](https://github.com/ramonfontes/mn-wifi-ebook/blob/main/expert.md#interaction-between-virtual-and-real-environments) 80 | - [Decoding packets](https://github.com/ramonfontes/mn-wifi-ebook/blob/main/expert.md#decoding-packets) 81 | - [Association control](https://github.com/ramonfontes/mn-wifi-ebook/blob/main/expert.md#association-control) 82 | - [Forwarding by SSID](https://github.com/ramonfontes/mn-wifi-ebook/blob/main/expert.md#forwarding-by-ssid) 83 | - [Security](https://github.com/ramonfontes/mn-wifi-ebook/blob/main/expert.md#security) 84 | - [ARP Spoofing](https://github.com/ramonfontes/mn-wifi-ebook/blob/main/expert.md#arp-spoofing) 85 | - [Cracking WEP Keys](https://github.com/ramonfontes/mn-wifi-ebook/blob/main/expert.md#cracking-wep-keys) 86 | - [Discovering WPA/WPA2 keys](https://github.com/ramonfontes/mn-wifi-ebook/blob/main/expert.md#discovering-wpawpa2-keys) 87 | - [The Krack Attack](https://github.com/ramonfontes/mn-wifi-ebook/blob/main/expert.md#the-krack-attack) 88 | - [Intrusion Detection System (IDS)](https://github.com/ramonfontes/mn-wifi-ebook/blob/main/expert.md#intrusion-detection-system-ids) 89 | - [Centralized Authentication](https://github.com/ramonfontes/mn-wifi-ebook/blob/main/expert.md#centralized-authentication) 90 | - [Radius and SDN](https://github.com/ramonfontes/mn-wifi-ebook/blob/main/expert.md#radius-and-sdn) 91 | - [6LoWPAN / IoT](https://github.com/ramonfontes/mn-wifi-ebook/blob/main/expert.md#6lowpan--iot) 92 | - [Vehicular ad hoc networks](https://github.com/ramonfontes/mn-wifi-ebook/blob/main/expert.md#vehicular-ad-hoc-networks) 93 | -------------------------------------------------------------------------------- /background.md: -------------------------------------------------------------------------------- 1 | ## Background 2 | 3 | ## Wireless communications 4 | 5 | Wireless communications continues to be one of the most vibrant fields in the telecommunications sector. Although they began in the late nineteenth and early twentieth centuries, wireless communication research and development activities intensified between the 1970s to 1990s, fueled by a growing demand for increasingly better connectivity. Initially driven by the development of cell phones for voice services and then data applications, wireless technologies keep evolving, fostered by new forms of content creation and consumption and interaction between humans, machines and everyday objects, a trend commonly known as the Internet of Things (IoT). 6 | 7 | 8 | Conventional wireless communication networks encompass several elements, the most basic of which are listed below: (i) the wireless terminals - such as laptops, smartphones, which are the interface between the user and the network; (ii) radio links, which connect the terminals to an agent providing the network coverage service; (iii) base stations, which function as the coverage agents; (iv) switching and control centers, which concentrate the base stations and connect them to other communication services. 9 | 10 | 11 | ![RSSI](figures/propagationRSSI-en.png "RSSI") 12 | 13 | 14 | There are numerous technologies that provide wireless services, such as Bluetooth, LTE, Zigbee, WiFi, among other means. Wireless communications have unique features that make them distinct from other technologies. One of them, and certainly the most important one, is the propagation of radio waves. A signal propagating from one point to another undergoes three types of phenomena, namely: attenuation, long-term fading and short-term fading. Attenuation refers to loss of transmission when the receiver moves away from the source. Long-term fading refers to conditions when the average signal changes slowly over time due to obstructions to the signal path, such as buildings, trees, etc. Short-term fading refers to quick fluctuations of the signal due to reflection, scattering and diffraction. There is also the problem of interference by services using the same frequency or even approximate frequencies. 15 | 16 | 17 | Due to the increasing worldwide demand for wireless communications, new technologies are emerging so that systems can meet this demand. In any case, the development of any system, and, more specifically, wireless systems, requires a deep knowledge of the phenomena involved. Figure below exemplifies the phenomenon of path loss by showing how the Received Signal Strength Indicator (RSSI), in dBm, oscillates in relation to the physical distance between a base station and a wireless station. The figure compares the estimations of different propagation models described in the literature (_Free-Space, Log-Distance, ITU_) - which are available in the Mininet-WiFi emulator - compared to measurements taken in a laboratory environment, the [R2Lab](https://r2lab.inria.fr) testbed. Figure below, in turn, illustrates the phenomena of long-term and short-term fading. 18 | 19 | 20 | ![Effect of path loss](figures/fading-en.png "Effect of path loss") 21 | 22 | - H. Waldman e M. D. Yacoub, _Telecomunicações: Princípios e Tendências_, Editora Érica, 1997. ISBN: 978-8571944374 23 | - J. C. de Oliveira Medeiros. _Princípios de Telecomunicações. Teoria e Prática_. Editora Érica, 2015. ISBN: 978-8536516288 24 | - M. D. Yacoub, _Foundations Of Mobile Radio Engineering_. CRC Press, 1993. ISBN: 978-0849386770 25 | - M. D. Yacoub, _Wireless Technology: Protocols, Standards, and Techniques_, CRC Press, 2001. ISBN: 978-0849309694 26 | - C. J. Weisman, _The Essential Guide to RF and Wireless_. Prentice Hall. 2002. ISBN: 978-0130354655 27 | - T. Rappaport, _Wireless Communications: Principles and Practice_, Pearson Education India, 2010. ISBN: 978-0130422323 28 | - A. K. Jagannatham, _Principles of Modern Wireless Communication Systems Theory and Practice_. McGraw Hill Education, 2017. ISBN: 978-1259029578 29 | 30 | 31 | ## WiFi: IEEE 802.11-based wireless local area networks 32 | 33 | Established by the Institute of Electrical and Electronics Engineers (IEEE), IEEE 802.11 is the most accepted wireless communications standard in the world. WiFi technology, as it is most commonly known, is the Wireless Local Area Network (WLAN) technology based on IEEE 802.11, and it is a trademark of the Wi-Fi Alliance. The reasons for the wide acceptance of this pattern are diverse, but the main justification is cost-performance ratio.\\ 34 | 35 | 36 | ![IEEE 802.11 modes](figures/wifi-padroes-en.png "IEEE 802.11 modes") 37 | 38 | 39 | As illustrated in the figure above, there are several 802.11 standards, such as the older 802.11b, 802.11a, and 802.11g versions, and other versions that may be considered as newer, such as 802.11n, 802.11ac, 802.11p, and so on. In general, the standards defined for 802.11 operate on two main frequencies: 2.4 GHz or 5 GHz. In the example given by the figure below, it can be seen how the 802.11b standard defines 13 channels on the 2.4 GHz band at 2.4835 Ghz, allocating 22 MHz for each channel, with a spacing of 5 MHz among them. With this arrangement, only channels 1, 6 and 11 can operate without band overlap. 40 | 41 | ![IEEE 802.11b channels](figures/802-11-b-channels.jpg "IEEE 802.11b channels. Source: adapted from cite{BinNgadi2012}~(CC BY 2.0)") 42 | 43 | The Bit Error Rate (BER), which is a requirement to be fulfilled in the system design, can be determined by knowing the modulation scheme, the type of encoding and the signal-to-noise ratio (SNR). It is known that an increase in transmitter power results in a higher SNR and a consequent decrease in BER. Obviously, power cannot be increased indefinitely, due to interference and to power limitations in the transmitter itself. 44 | 45 | 46 | Table below compares different 802.11 standards in terms of operating frequency, channel bandwidth and coverage radius estimates in indoor and outdoor environments. 47 | 48 | | **Protocol** | **Freq. (GHz)** | **Bandwidth (MHz)** | **Internal Signal Range** | **External Signal Range** | 49 | |------------------|---------------------|--------------------------|--------------------------------|--------------------------------| 50 | | 802.11 | 2.4 | 20 | 20 m / 66 ft | 100 m / 330 ft | 51 | | 802.11a | 3.7/ 5 | 20 | 35 m / 115 ft | 120 m / 390 ft | 52 | | 802.11b | 2.4 | 20 | 35 m / 115 ft | 140 m / 460 ft | 53 | | 802.11g | 2.4 | 20 | 38 m / 125 ft | 140 m / 460 ft | 54 | | 802.11n | 2.4/5 | 20 - 40 | 70 m / 230 ft | 250 m / 820 ft | 55 | | 802.11ac | 5 | 20/40/80/160 | 35 m / 115 ft | n/d | 56 | | 802.11ad | 60 | 2,160 | 60 m / 200 ft | 100 m / 300 ft | 57 | | 802.11ay | 60 | 8000 | 60 m / 200 ft | 1000 m / 3000 ft | 58 | 59 | 60 | Table below compares 802.11n and 802.11ac, two of the newer standards that incorporate recent advances in wireless communications, such as spatial flows based on MIMO (Multiple Input Multiple Output).\\ 61 | 62 | 63 | | | **IEEE 802.11n** | **IEEE 802.11ac** | 64 | |----------------------------------|-----------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------| 65 | | Frequency | 2.4 GHz \ 5 GHz | 5 GHz 66 | | MIMO | Single User (SU) | Multi User (MU) | 67 | | Spatial Flows | 4 | 8 | 68 | | Taxa PHY | 600 Mbps | 6.9 Gbps | 69 | | Channel Width | 20 or 40 MHz |20, 40, 80, 80-80, 160 MHz 70 | | Modulation | 64 QAM | 256 QAM | 71 | | Flow rate MAC* | 390 Mbps | 4.49 Gbps | 72 | 73 | 74 | The 802.11 architecture consists primarily of an access point and a number of wireless stations (clients). In this case, the architecture is defined as Basic Service Set (BSS), or infrastructure mode. In contrast, 802.11 networks composed of only wireless stations (clients) are referred to as Independent Basic Service Set (IBSS) or ad-hoc mode. The graphical representations of these two architectures (or modes of operation) are illustrated in Figures below. 75 | 76 | 77 | As is true with Ethernet devices, each 802.11 wireless device has a 6-byte MAC address stored on the network interface card. It is through the wireless network interface that stations can associate with an access point or even other client stations before receiving or sending 802.11 frames. 78 | 79 | ![infrastructure](figures/infra.png "infrastructure") 80 | 81 | ![adhoc](figures/adhoc.png "adhoc") 82 | 83 | 84 | Because wireless networks do not have the physical means to prevent collisions, these do happen even with the most advanced wireless technologies. While the IEEE 802 standards for Ethernet family cabling enable Collision Detection (CD), wireless networks have no means to detect a collision. The strategy adopted by the 802.11 standards to handle wireless access control is known as Carrier Sense Multiple Access with Collision Avoidance (CSMA/CA). 85 | 86 | 87 | When the CSMA/CA method is used, each station informs about its own transmission intent and the associated time for Collision Avoidance (CA). The stations, which are equipped with wireless interfaces, listen to the medium using wireless interfaces to verify the presence of signals (signal level at the carrier frequency) and wait until the medium is clear before transmitting. These mechanisms are known as Request to Send (RTS) and Clear to Send (CTS). 88 | 89 | 90 | Despite the similarities between Ethernet frames and 802.11 frames, there are several fields that are specific to wireless links. The fields in the 802.11 table are shown in the figure below. The numbers above each field in the frame represent their lengths in bytes, while the numbers above each of the sub-fields in the frame control field represent the lengths of the sub-fields in bits.\\ 91 | 92 | 93 | ![IEEE 802.11 frame header](figures/frame-header-en.png "IEEE 802.11 frame header") 94 | 95 | 96 | Although we do not go into detail about the function of each of the fields and sub-fields belonging to frame 802.11, it is advisable to know about them even if superficially. These fields may be useful for further exploration of some of the tutorials that will be presented throughout this book. 97 | 98 | #### The future of WiFi 99 | Although wireless networks are very important, there are still structural barriers that prevent their innovation, even with regard to WiFi itself. Furthermore, large wireless infrastructure is not completely accessible because there are restrictions on its use or authentication requirements. Namely, the issue here is not to open access to wireless networks completely and freely, but to allow users to connect to multiple networks (preserving security and quality standards), thus opening up a huge capacity for coverage and enabling continuous innovation. 100 | 101 | 102 | Nevertheless, there are already several studies on vehicular networks and also the Internet of Things that use WiFi in their methods. Many of them, of course, provide only suggestions for improvements that may advance 802.11 in the future. Yet it is not for nothing that researchers already speak of 802.11ax, an evolution of 802.11ac that promises to connect more devices with higher baud rates than its predecessor. 103 | 104 | 105 | Among the proposals for improvements and advancements in wireless networks and especially WiFi, is the concept of software-defined wireless networks, which also promises significant progress by constructing a new idea of connectivity. Therefore, along with the concept of software-defined wireless networks, this book will present a series of tutorials that will explore various cases involving Mininet-WiFi. Mininet-WiFi is the wireless emulator that we will use extensively throughout this book. It was developed with the aim of providing an environment capable of supporting research on wireless networks and software-defined wireless networks, enabling innovations to be developed for the most diverse wireless technologies. 106 | 107 | - Matthew S. Gast._ 802.11 Wireless Networks: The Definitive Guide_. O'Reilly Media, 2005. ISBN-13: 978-0596100520 108 | - Matthew S. Gast. _802.11ac: A Survival Guide: Wi-Fi at Gigabit and Beyond_. O'Reilly Media (Edição: 2), 2013. ISBN-13: 978-1449343149 109 | - Jim Geier, _Designing and Deploying 802.11 Wireless Networks: A Practical Guide to Implementing 802.11n and 802.11ac Wireless Networks For Enterprise-Based Applications_. Cisco Press, 2015. ISBN-13: 978-1587144301 110 | - IEEE 802.11 Wireless Local Area Networks. The Working Group for WLAN Standards. Available at: http://www.ieee802.org/11_ 111 | 112 | 113 | ## Software-defined wireless networking 114 | Software-defined wireless networking (SDWN) is an approach that allows centralized control of the network through the use of programs that do not necessarily have to be located in access points. Thus, rules defined by these programs (commonly known as controllers) dictate the behavior of the network. The principles of SDWN, which separate the control plane from the data plane, are very similar to those of software-defined networks (SDN). 115 | 116 | 117 | The software-defined approach allows network administrators to specify network behavior in a logical and centralized way. To do so, they use programs provided by control platforms that implement southbound interfaces on network devices such as switches. In this context, the OpenFlow protocol is the most popular southbound interface. However, there are other viable interfaces, such as CAPWAP, FORCES, NETCONF, etc. 118 | 119 | ![High-level and generic architecture for SDWN. Source: Adapted from cite{DBLP:journals/cj/FontesMDTR17}](figures/sdwn-en.png "High-level and generic architecture for SDWN. Source: Adapted from cite{DBLP:journals/cj/FontesMDTR17}") 120 | 121 | 122 | Due to the increased interest of mobile operators, mainly in Network Function Virtualization (NFV), SDWN has become a branch of software-defined networks of considerable interest to the scientific community. The separation between the control plane and the data plane is not new in the history of wireless networks. The IETF standardized both the LWAPP (Lightweight Access Point Protocol) and the CAPWAP (Control and Provisioning of Wireless Access Points) many years ago by issuing RFC5412 and RFC4564, respectively - even before the development of software-defined networks and the OpenFlow protocol. 123 | 124 | 125 | Many companies use wireless network management systems by means of protocols such as LWAPP and CAPWAP. LWAPP defines message control for configuration, authentication and other operations, while CAPWAP is based on LWAPP and allows a controller to manage different access points. 126 | 127 | 128 | The number of studies on software-defined wireless networks has grown significantly in recent years. It is worth reading for a more comprehensive survey, in addition to some software projects, such as: OpenRoads, Odin, OpenRF, Ethanol. Architectures such as CloudMac and Chandelle use CAPWAP in their code. CloudMac describes wireless network management protocols, such as CAPWAP, as difficult to be configured with new features, since access point controllers that use CAPWAP are mostly proprietary systems. Chandelle, on the other hand, proposes a migration between smooth and fast access points using SDN/OpenFlow, but faces integration issues with regard to traditional switches and CAPWAP. 129 | 130 | 131 | info It is important to mention that there is an open source implementation of the CAPWAP protocol that is compatible with RFC 4515 and RFC 4516, called OpenCAPWAP, whose development started in 2015 (https://github.com/vollero/openCAPWAP). 132 | 133 | The benefits of integrating wireless networks with OpenFlow generally involve centralized management and monitoring, unified policies, greater scheduling, and better control of wireless functions. 134 | 135 | 136 | Taking into account these benefits and the limitations associated with CAPWAP, which is likely to be a more robust but closed-source solution, some questions are unavoidable: _Is CAPWAP compatible with SDWN?_, _How to improve the OpenFlow specification, so that it supports centralized management of wireless networks? Or even, could you extend it to wireless networks?_, _Are new approaches needed?_ or _How much could be recycled from the existing infrastructure?_. 137 | 138 | 139 | - L. E. Li, Z. M. Mao and J. Rexford, _Toward Software-Defined Cellular Networks_. European Workshop on Software Defined Networking (EWSDN), 2012. 140 | - A. Gudipati et al., _SoftRAN: software defined radio access network_. Proceedings of Hot topics in software defined networking (HotSDN). 2013. 141 | - C. J. Bernardos et al., _An architecture for software defined wireless networking_. IEEE Wireless Communications. 2014. 142 | - T. Chen et al., _Software defined mobile networks: concept, survey, and research directions_, IEEE Communications Magazine. 2015. 143 | - Mao Yang et al., _Software-Defined and Virtualized Future Mobile and Wireless Networks: A Survey_. Mob. Netw. Appl. 2015. 144 | - I. T. Haque and N. Abu-Ghazaleh, _Wireless Software Defined Networking: A Survey and Taxonomy_, in IEEE Communications Surveys \& Tutorials. 2016. 145 | - A. Abdelaziz et al. _On Software-Defined Wireless Network (SDWN) Network Virtualization: Challenges and Open Issues_. Computer Journal. 2017. 146 | - [Linux Foundation’s Open Networking Foundation (ONF) SDN Wireless Transport.](https://www.opennetworking.org/tag/wireless-transport/) 147 | 148 | ## Mininet-WiFi 149 | 150 | Network emulation has been widely used in performance evaluation, protocol testing and debugging, as well as in a variety of research on computer network architectures. A researcher typically has several possible methods to evaluate and validate research data and network protocols, as well as perform analyses, among other operations. 151 | 152 | 153 | Simulators, emulators and testbeds are the main evaluation tools that help researchers in their tasks. Still, regarding their practical applications, all these evaluation tools are very different in their degree of abstraction. Some of the experimental platforms that can be used for experimentation with wireless networks are shown in the figure below. In this research field, the emulation of wireless networks - which has peculiar characteristics, especially compared with emulators for wired networks - has to implement node mobility, signal propagation, among other features, to allow experiments with environments that have interference, signal attenuation, etc.\\ 154 | 155 | ![Experimental platforms for wireless networks. Source: Adapted from cite{7367387}.](figures/related-work-en.png "Experimental platforms for wireless networks. Source: Adapted from cite{7367387}.") 156 | 157 | We will not go into detail about the differences between experimental platforms, but we can highlight two important features of Mininet-WiFi: (i) it allows the use of third-party tools without modifications to the source code of these tools, and (ii) it uses the actual network protocol stack. 158 | 159 | 160 | Mininet-WiFi is an emulator for wireless networks that was extended from Mininet, a well-known emulator to researchers working in the field of software-defined networks. Mininet-WiFi has native WiFi support, but other wireless networking technologies can also be simulated in experiments using it. With Mininet-WiFi, the user can virtualize stations and access points and also use existing Mininet nodes such as hosts, switches and OpenFlow controllers. Consequently, Mininet-WiFi also enables the processing of packages using the OpenFlow protocol, an important solution for SDN. 161 | 162 | info SoftMAC is a term used to describe a type of wireless network interface in which the MAC Layer Management Entity (MLME), for example, is expected to be managed using software. Mac80211 is a driver API for SoftMAC. 163 | 164 | Mininet-WiFi is developed based on the Mininet code and the most used WiFi _driver_ for Linux systems, _SoftMac_. With Mininet-WiFi, the user can choose to use the old Mininet features independently or use the extensions implemented for Mininet-WiFi. 165 | 166 | 167 | ### Architecture 168 | The entire virtualization process of Mininet-WiFi works similarly to Mininet, i.e. it is based on processes that run on Linux network namespaces and virtual network interfaces. Linux network namespaces are, in a logical sense, copies of the Linux operating system's network stack, which includes its own routes, firewall rules and network devices. They act as if they were real computers, with the same network properties that a physical computer can have.\\ 169 | 170 | ![Mininet-WiFi architecture. Source: cite{7367387}](figures/arch.png "Mininet-WiFi architecture. Source: cite{7367387}") 171 | 172 | The behavior of wireless interfaces basically depends on the function they perform, such as, for instance, the case of stations and access points, whose interfaces operate in the managed or master modes, respectively. Just as with a real environment, the stations communicate with access points by a process called authentication and association. By default, each station has only one wireless interface, and more can be added if needed. Once connected to an access point, stations can communicate with traditional Mininet hosts, if they are also connected to the access point. Access points, on the other hand, are responsible for managing stations that are associated with them. 173 | 174 | 175 | Conceptually, access points are the same entities as the Mininet switches, but equipped with WiFi network cards operating in master mode. Access points are virtualized in the _hostapd_ daemon, which basically uses virtual WiFi interfaces to provide access point capabilities. Details on the running environment of Mininet-WiFi are discussed below. 176 | 177 | 178 | ### Components 179 | 180 | ![Main components of Mininet-WiFi. Source: cite{7367387}](figures/components.png "Main components of Mininet-WiFi. Source: cite{7367387}") 181 | 182 | The components comprising the Mininet-WiFi architecture are shown in the figure above. Communication among them occurs as follows: during its initialization, the module called _mac80211\_hwsim_, responsible for the virtualization of WiFi network cards, is loaded with the number of virtual wireless interfaces required for all nodes previously defined by the user. Located in the kernel space of the Linux operating system, all features supported by _mac80211\_hwsim_ come from mac80211, a framework based on _SoftMAC_ that developers use to write drivers for wireless devices. 183 | 184 | 185 | Also in the kernel space is _cfg80211_, which is an 802.11 heap configuration API for Linux systems. Its configuration is done by running _nl80211_, which also performs the interaction between kernel and user spaces. 186 | 187 | 188 | The main network applications used by Mininet-WiFi are in the user space. Among them is _hostapd_, whose function is to provide access point services; the TC and Wmediumd programs, which will be described below; _iw_, _iwconfig_ and _wpa\_supplicant_. The latter is used for, among other tasks, WPA/WPA2 authentication. 189 | 190 | 191 | #### Interacting with the emulation environment 192 | 193 | Mininet-WiFi also maintains the same interaction structure as Mininet. E.g., commands such as those shown below can be used, respectively, for connectivity tests or to measure th bandwidth between two nodes. If you are already familiar with Mininet, this is certainly nothing new. 194 | 195 | ``` 196 | mininet-wifi> sta1 ping sta2 197 | mininet-wifi> iperf sta1 sta2 198 | ``` 199 | 200 | 201 | In addition to these, other commands exclusive to Mininet-WiFi can be used for a better experience with the WiFi environment, such as the ones described below: 202 | 203 | 204 | ``` 205 | mininet-wifi> sta1 iw dev sta1-wlan0 scan 206 | mininet-wifi> sta1 iw dev sta1-wlan0 connect ssid-ap1 207 | ``` 208 | 209 | These commands allow you to scan WiFi networks and connect to one of them, respectively. Scripts such as _iw_, the command used above, are natively supported by most Linux operating systems and have not been ported or modified to work on Mininet-WiFi. Mininet-WiFi can execute any command and/or program that runs on Linux distributions, such as Ubuntu. 210 | 211 | - Ramon dos Reis Fontes, Samira Afzal, Samuel Brito, Mateus Santos, Christian Esteve Rothenberg. _Mininet-WiFi: Emulating Software-Defined Wireless Networks._ In 2nd International Workshop on Management of SDN and NFV Systems 2015. Barcelona, Spain, Nov. 2015. 212 | - Ramon dos Reis Fontes, _Mininet-WiFi: Emulation Platform for Software-Defined Wireless Networks_. Tese de Doutorado em Engenharia Elétrica, FEEC/UNICAMP, Jun. 2018. Available at: http://repositorio.unicamp.br/jspui/bitstream/REPOSIP/332708/1/Fontes_RamonDosReis\_D.pdf 213 | -------------------------------------------------------------------------------- /beginner.md: -------------------------------------------------------------------------------- 1 | # Beginner 2 | 3 | In this chapter we introduce Mininet-WiFi and all features supported by this emulator, highlighting critical information necessary to understand the tutorials explored throughout this book. We begin by discussing all steps needed to get Mininet-WiFi up and running on your computer. 4 | 5 | 6 | ## Downloading and installing Mininet-WiFi 7 | 8 | The Mininet-WiFi source code is a _Git repository_ publicly available on _Github_. Git is an amazing open source system, capable of handling the distributed version control of any given project, in this case the Mininet-WiFi project. It was devised by [Linus Torvalds](github.com/torvalds) himself as a means of helping the development, at the time, of a tiny project called Linux. 9 | 10 | 11 | To ease the searching and following-up of projects managed by Git, developers usually share their Git repository on Github, a platform for creating, managing, further distributing and interacting with open-source projects. This means that the life cycle of a project can be easily analyzed by contributors through Github, which keeps any file's modification history since its origin. In this book we only use the basic concepts of the Git system. For more information about Git and Github, please refer to <_git-scm.com_> and <_github.com_>. 12 | 13 | 14 | To obtain Mininet-WiFi's source code and install it, you will need to perform a process called cloning, in which all the information pertaining to a project is downloaded to your computer. Since Mininet-WiFi is a Git repository on Github, its cloning is carried out using the Git system. 15 | 16 | 17 | After this brief introduction to Git and Github, you can clone the Mininet-WiFi source code by using the following command line, which consists of the instruction git clone followed by a link to Mininet-Wifi's Github repository. 18 | 19 | ``` 20 | ~$ git clone https://github.com/intrig-unicamp/mininet-wifi 21 | ``` 22 | 23 | warning Mininet-WiFi relies on Linux Kernel components to function properly. Of the different Linux distributions that can be used to this end, we recommend Ubuntu, since Mininet-WiFi was extensively tested on it. 24 | 25 | 26 | In the link to Mininet-WiFi's repository, _intrig-unicamp_ refers to the profile or organization where the repository is located on Github. _mininet-wifi_, in turn, is the name of the repository where the source code is deposited. 27 | 28 | warning If you do not have _git_, you can install it using the `sudo apt install git` command. 29 | 30 | Once the clone is complete, a directory named <_mininet-wifi_> should be created. Since the cloning was done from the user's directory, the Mininet-WiFi source code should be located at , or simply <_~/mininet-wifi_>. 31 | 32 | 33 | Now you need to install Mininet-WiFi. To do so, you will need to access the created directory and execute the `sudo util/install.sh` command, as follows. 34 | 35 | ``` 36 | ~$ cd mininet-wifi 37 | ~/mininet-wifi$ sudo util/install.sh -Wlnfv6 38 | ``` 39 | 40 | info Further information on the _Wlnfv6_ parameters can be found on the Mininet-WiFi source code page on Github. 41 | 42 | Alternatively, you can also use the virtual machine available on the source page. To ensure that the virtual machine has the latest version of Mininet-WiFi, you must use the commands below. 43 | 44 | ``` 45 | ~/mininet-wifi$ git pull 46 | ~/mininet-wifi$ sudo make install 47 | ``` 48 | 49 | warning Capturing the code through the `git clone` command ensures that the source code will always contain the latest updates implemented for Mininet-WiFi. 50 | 51 | Even if you already have Mininet-WiFi and/or the virtual machine installed, the `git pull` command can be issued from the Mininet-WiFi directory at any time. This command will synchronize the code that is on your computer with the source code available in the Mininet-WiFi source code repository. By doing this, you will always have the latest version of Mininet-WiFi installed. 52 | 53 | ## First steps to use Mininet-WiFi 54 | 55 | In the following paragraphs, we will begin to understand how to use Mininet-WiFi. 56 | 57 | 58 | First, we need to be aware of three commands: `sudo mn --version`, which prints the Mininet-WiFi version in use; `sudo mn --help`, which prints a help menu; and `sudo mn -c`, which is responsible for cleaning up poorly-made Mininet-WiFi executions. Remember this last command, because it will be very useful later on. 59 | 60 | 61 | Mininet-WiFi can be started by running a very simple command, `sudo mn --wifi`. In addition to opening the Command Line Interface (CLI), this command will create a topology consisted of two stations connected to an access point via a wireless medium, as well as an SDN controller that is connected to the access point, as shown in the figure below. 62 | 63 | ![Simple topology](figures/topo-wifi.png "Simple topology") 64 | 65 | ``` 66 | ~/mininet-wifi$ sudo mn --wifi 67 | *** Creating network 68 | *** Adding controller 69 | *** Adding stations: 70 | sta1 sta2 71 | *** Adding access points: 72 | ap1 73 | *** Configuring wifi nodes... 74 | *** Adding link(s): 75 | (sta1, ap1) (sta2, ap1) 76 | *** Configuring nodes 77 | *** Starting controller(s) 78 | c0 79 | *** Starting switches and/or access points 80 | ap1 ... 81 | *** Starting CLI: 82 | mininet-wifi> 83 | ``` 84 | 85 | infoIf you already know Mininet, you have probably already used the `sudo mn` command, which creates a simple topology with two hosts, one switch and one OpenFlow controller, connected by a wired medium. 86 | 87 | warning If you notice an error similar to the one below, it means that there is a controller or process already running on port 6653, the default port used by the most recent OpenFlow controllers. This problem can be solved using the `sudo fuser -k 6653/tcp` command, which will kill the process that is using port 6653. If the controller is running on port 6633, the same must be done with this port number. 88 | 89 | ``` 90 | Exception: Please shut down the controller which is running on port 6653: 91 | Active Internet connections (servers and established) 92 | tcp 0 0 0.0.0.0:6653 0.0.0.0:* LISTEN 2449/ovs-testcontro 93 | tcp 0 0 127.0.0.1:55118 127.0.0.1:6653 TIME_WAIT - 94 | ``` 95 | 96 | To identify the Mininet-WiFi CLI, just search for the text below: 97 | 98 | ``` 99 | mininet-wifi> 100 | ``` 101 | 102 | Within the CLI you can essentially use any network commands or programs. Additionally, it is also possible to list and execute a number of commands that have been implemented exclusively for Mininet-WiFi. The `help` command allows you to list available commands, as follows. 103 | 104 | ``` 105 | mininet-wifi> help 106 | Documented commands (type help ): 107 | ======================================== 108 | EOF exit iperf nodes pingpair py start x 109 | distance gterm iperfudp noecho pingpairfull quit stop xterm 110 | dpctl help links pingall ports sh switch 111 | dump intfs net pingallfull px source time 112 | ``` 113 | 114 | Most of these commands already existed in Mininet and were kept for Mininet-WiFi. Only three new commands have been added to Mininet-WiFi: `distance`, `start` and `stop`. `distance` allows you to check the distance between two nodes, while `start` and `stop` allow you to pause and continue experiments that implement node mobility. 115 | 116 | warning This book will demonstrate the commands implemented for Mininet-WiFi, in addition to some others already implemented on Mininet. 117 | 118 | Try using the `nodes` command to identify nodes that are part of the topology. Note that the nodes described by the `nodes` command are the same as those shown previously in https://github.com/ramonfontes/mn-wifi-ebook/raw/main/figures/topo-wifi.png. 119 | **Note**: Node **c0** will be discussed later. 120 | 121 | ``` 122 | mininet-wifi> nodes 123 | available nodes are: 124 | ap1 c0 sta1 sta2 125 | ``` 126 | 127 | As previously mentioned, the `sudo mn --wifi` command creates a topology with stations that are connected through a wireless medium to an access point. This can be easily verified using wireless networking tools. 128 | 129 | 130 | Although the `sudo mn --wifi` command creates an AP with an SSID called `my-ssid` operating on channel 1 (2412MHz), these values can also be customized. For instance, we will exit the Mininet-WiFi CLI with the `exit` command and then set up a new SSID and a new channel, as follows: 131 | 132 | ``` 133 | mininet-wifi> exit 134 | ~/mininet-wifi$ sudo mn --wifi --ssid=new-ssid --channel=10 135 | ``` 136 | 137 | Then try the following command. 138 | 139 | ``` 140 | mininet-wifi> sta1 iw dev sta1-wlan0 info 141 | Interface sta1-wlan0 142 | ifindex 33 143 | wdev 0x1000000001 144 | addr 02:00:00:00:00:00 145 | ssid new-ssid 146 | type managed 147 | wiphy 16 148 | channel 10 (2457 MHz), width: 20 MHz (no HT), center1: 2457 MHz 149 | txpower 14.00 dBm 150 | ``` 151 | 152 | If you are new to wireless networking, especially on Linux operating systems, you might not have noticed, but you have just used a very common program in wireless networking environments, the _iw_ tool. _iw_ is a utility for wireless networks that is gradually replacing _iwconfig_. We will use it extensively throughout this book. 153 | 154 | info _iwconfig_ is certainly already installed on your system and you can also use it. For example, _sta1 iwconfig_ will produce a similar result to the one shown previously by _iw_. Try running `iwconfig --help` for more information on how to use it. 155 | 156 | With respect to the command that we have just used, the _info_ parameter brings up information about the association (or no association) between nodes. It is noticeable that **sta1** is associated with an access point with a SSID _new-ssid_ that also operates on channel 10, exactly as defined by the command. 157 | 158 | 159 | Additionally, using the _link_ parameter instead of _info_ allows the user to obtain the signal level perceived by the node and the _bitrate_, in addition to transmitted and received packets, among other data. 160 | 161 | ``` 162 | mininet-wifi> sta1 iw dev sta1-wlan0 link 163 | Connected to 02:00:00:00:02:00 (on sta1-wlan0) 164 | SSID: new-ssid 165 | freq: 2457 166 | RX: 1241 bytes (22 packets) 167 | TX: 93 bytes (2 packets) 168 | signal: -36 dBm 169 | tx bitrate: 1.0 MBit/s 170 | 171 | bss flags: short-slot-time 172 | dtim period: 2rendering this PDF. 173 | 174 | beacon int: 100 175 | ``` 176 | 177 | 178 | Now, let us use the _ping_ command to verify the connectivity between **sta1** and **sta2**. 179 | 180 | ``` 181 | mininet-wifi> sta1 ping -c1 sta2 182 | PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data. 183 | 64 bytes from 10.0.0.2: icmp_seq=1 ttl=64 time=0.380 ms 184 | 185 | --- 10.0.0.2 ping statistics --- 186 | 1 packets transmitted, 1 received, 0% packet loss, time 0ms 187 | rtt min/avg/max/mdev = 0.380/0.380/0.380/0.000 ms 188 | ``` 189 | 190 | The command shows that there is communication between the two nodes in question, since it also displays a response time in milliseconds belonging to **sta2**(_ms_). It is important to note that because Mininet-WiFi is an emulation platform capable of emulating several nodes, it is necessary to define in the CLI the source node that will be responsible, in practice, for issuing a given command. 191 | 192 | infoThe `-c1` parameter used with the _ping_ command means that only one ICMP packet will be sent. Otherwise, **sta1** will send endless ICMP packets. 193 | 194 | Thus, as the _ping_ command needs a target node - which can be either a name or an IP address -, **sta2**'s destination can also be replaced by its IP address. As can be seen below, the IP address that identifies **sta2** is 10.0.0.2/8. 195 | 196 | 197 | ``` 198 | mininet-wifi> sta2 ip addr 199 | 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 200 | link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 201 | inet 127.0.0.1/8 scope host lo 202 | valid_lft forever preferred_lft forever 203 | inet6 ::1/128 scope host 204 | valid_lft forever preferred_lft forever 205 | 34: sta2-wlan0: mtu 1500 qdisc htb state UP group default qlen 1000 206 | link/ether 02:00:00:00:01:00 brd ff:ff:ff:ff:ff:ff 207 | inet 10.0.0.2/8 scope global sta2-wlan0 208 | valid_lft forever preferred_lft forever 209 | inet6 fe80::ff:fe00:100/64 scope link 210 | valid_lft forever preferred_lft forever 211 | ``` 212 | 213 | 214 | Alternatively, you can also open different terminals for each node and issue commands as if they were being sent directly to a computer, exactly as it happens in the real world. For example, the following command will open two terminals, one for **sta1** and another for **sta2**. Once there is a terminal for each node, it will no longer be necessary to indicate which one is the origin, as explained in the previous paragraph. 215 | 216 | ![Running xterm](figures/xterm.png "Running xterm") 217 | 218 | ``` 219 | mininet-wifi> xterm sta1 sta2 220 | ``` 221 | 222 | info _Xterm_ may not work as expected if there is no GUI enabled on your operating system. 223 | 224 | Now, we will perform a few routines and exclusive actions of the wireless environment. To begin, we will disconnect **sta1** from **ap1** and confirm the disassociation by issuing the following command:\\ 225 | 226 | ``` 227 | mininet-wifi> sta1 iw dev sta1-wlan0 disconnect 228 | mininet-wifi> sta1 iw dev sta1-wlan0 link 229 | Not connected. 230 | ``` 231 | 232 | So let us try a new _ping_ between **sta1** and **sta2**. 233 | 234 | ``` 235 | mininet-wifi> sta1 ping -c1 sta2 236 | PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data. 237 | From 10.0.0.1 icmp_seq=1 Destination Host Unreachable 238 | 239 | --- 10.0.0.2 ping statistics --- 240 | 1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms 241 | ``` 242 | 243 | As you can see, station **sta1** is no longer associated with access point **ap1**, so it would be logically impossible to perform any kind of communication with **sta2**. 244 | 245 | 246 | Now, we will connect **sta1** again to the **ap1** access point and confirm the association. 247 | 248 | ``` 249 | mininet-wifi> sta1 iw dev sta1-wlan0 connect new-ssid 250 | mininet-wifi> sta1 iw dev sta1-wlan0 link 251 | Connected to 02:00:00:00:02:00 (on sta1-wlan0) 252 | SSID: new-ssid 253 | freq: 2457 254 | RX: 370 bytes (9 packets) 255 | TX: 202 bytes (3 packets) 256 | signal: -36 dBm 257 | tx bitrate: 6.0 MBit/s 258 | 259 | bss flags: short-slot-time 260 | dtim period: 2 261 | beacon int: 100 262 | ``` 263 | 264 | And then we will try a new _ping_ between **sta1** and **sta2**. The _ping_ command should run successfully, as follows. 265 | 266 | ``` 267 | mininet-wifi> sta1 ping -c1 sta2 268 | PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data. 269 | 64 bytes from 10.0.0.2: icmp_seq=1 ttl=64 time=1011 ms 270 | 271 | --- 10.0.0.2 ping statistics --- 272 | 1 packets transmitted, 1 received, 0% packet loss, time 0ms 273 | rtt min/avg/max/mdev = 1011.206/1011.206/1011.206/0.000 ms 274 | ``` 275 | 276 | Another very useful operation for WiFi networks is scanning, which allows you to check which access points a certain station can see. For example, let us assume that the SSID of access point **ap1** is unknown. In this case, the following command can be used to display **ap1**'s SSID. 277 | 278 | ``` 279 | mininet-wifi> sta1 iw dev sta1-wlan0 scan 280 | BSS 02:00:00:00:02:00(on sta1-wlan0) -- associated 281 | TSF: 1534710096681871 usec (17762d, 20:21:36) 282 | freq: 2457 283 | beacon interval: 100 TUs 284 | capability: ESS ShortSlotTime (0x0401) 285 | signal: -36.00 dBm 286 | last seen: 0 ms ago 287 | Information elements from Probe Response frame: 288 | SSID: new-ssid 289 | Supported rates: 1.0* 2.0* 5.5* 11.0* 6.0 9.0 12.0 18.0 290 | DS Parameter set: channel 1 291 | ERP: Barker_Preamble_Mode 292 | Extended supported rates: 24.0 36.0 48.0 54.0 293 | Extended capabilities: 294 | * Extended Channel Switching 295 | * Operating Mode Notification 296 | ``` 297 | 298 | 299 | ## Customizing topologies 300 | 301 | Different topologies can be created in Mininet-WiFi, through simple commands or even by using scripts written in _Python_. 302 | 303 | 304 | The topologies that can be created through commands are _single_ and _linear_. To generate these two kinds of topologies, we will need to close Mininet-WiFi. 305 | 306 | ``` 307 | mininet-wifi> exit 308 | ``` 309 | 310 | So let us start with the _single_ topology, which consists of one access point, **ap1**, and n stations associated with it. For example, the following command creates four stations, one access point and one SDN controller, as shown in the figure below. 311 | 312 | ``` 313 | ~/mininet-wifi$ sudo mn --wifi --topo single,4 314 | ``` 315 | 316 | ![Single topology](figures/topo-single.png "Single topology") 317 | 318 | At this point, we can test the connectivity between all the nodes by issuing the `pingall` command, as follows. 319 | 320 | ``` 321 | mininet-wifi> pingall 322 | *** Ping: testing ping reachability 323 | sta1 -> *** sta1 : ('ping -c1 10.0.0.2',) 324 | PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data. 325 | 64 bytes from 10.0.0.2: icmp_seq=1 ttl=64 time=0.170 ms 326 | 327 | --- 10.0.0.2 ping statistics --- 328 | 1 packets transmitted, 1 received, 0% packet loss, time 0ms 329 | rtt min/avg/max/mdev = 0.170/0.170/0.170/0.000 ms 330 | sta2 *** sta1 : ('ping -c1 10.0.0.3',) 331 | PING 10.0.0.3 (10.0.0.3) 56(84) bytes of data. 332 | 64 bytes from 10.0.0.3: icmp_seq=1 ttl=64 time=0.121 ms 333 | 334 | --- 10.0.0.3 ping statistics --- 335 | 1 packets transmitted, 1 received, 0% packet loss, time 0ms 336 | rtt min/avg/max/mdev = 0.121/0.121/0.121/0.000 ms 337 | sta3 *** sta1 : ('ping -c1 10.0.0.4',) 338 | PING 10.0.0.4 (10.0.0.4) 56(84) bytes of data. 339 | 64 bytes from 10.0.0.4: icmp_seq=1 ttl=64 time=0.129 ms 340 | 341 | --- 10.0.0.4 ping statistics --- 342 | 1 packets transmitted, 1 received, 0% packet loss, time 0ms 343 | rtt min/avg/max/mdev = 0.129/0.129/0.129/0.000 ms 344 | ``` 345 | 346 | The other topology that can be created using commands is _linear_, which consists of n access points and n stations, in which each station is associated with one access point and all the access points are connected in a linear way. For example, the following command creates four access points, four stations, and one SDN controller, as shown in the figure below. 347 | 348 | ``` 349 | ~/mininet-wifi$ sudo mn --wifi --topo linear,4 350 | ``` 351 | 352 | ![Linear topology](figures/topo-linear.png "Linear topology") 353 | 354 | The customization of topologies, on the other hand, is done by means of scripts that contain all the information about the topology as well as the configuration of its nodes. In the <_/mininet-wifi/examples_> directory there is a wide variety of scripts that can be used as a basis for creating custom topologies. 355 | 356 | 357 | It is always recommended that you check whether there is a script already developed for the scenario you want to work on. This helps you to create your own. Throughout this book we will use various scripts, which will certainly help in understanding how they can be customized. 358 | 359 | ## Accessing node information 360 | 361 | Now, let us learn how to get information from the nodes that make up a topology. To do so, we will create the simplest topology and add two new parameters: _position_ and _wmediumd_. The _position_ parameter will define initial positions for the nodes, while the _wmediumd_ parameter will enable _wmediumd_, a wireless simulator that will be shown in https://github.com/ramonfontes/mn-wifi-ebook/blob/main/beginner.md#wmediumd. 362 | 363 | ``` 364 | ~/mininet-wifi$ sudo mn --wifi --link=wmediumd --position 365 | ``` 366 | 367 | Then try issuing the `distance` command, as follows: 368 | 369 | ``` 370 | mininet-wifi> distance sta1 sta2 371 | The distance between sta1 and sta2 is 100.00 meters 372 | ``` 373 | 374 | Now, check the position of **sta1** and **sta2**. Note that the x, y, and z axes are separated by commas. 375 | 376 | ``` 377 | mininet-wifi> py sta1.position 378 | [1.0, 0.0, 0.0] 379 | 380 | mininet-wifi> py sta2.position 381 | [101.0, 0.0, 0.0] 382 | ``` 383 | 384 | As you can see, the initial positions were defined, and the `distance` command can be used to verify the distance between two nodes. 385 | 386 | 387 | At this point a question surely may arise: what if a specific position for a node must be defined? In this case, there are two possible solutions: either through the Mininet-WiFi CLI or scripts. The example below shows the `setPosition()` method, which can be used with the CLI and scripts. 388 | 389 | ``` 390 | mininet-wifi> py sta1.setPosition('10,0,0') 391 | ``` 392 | 393 | Note that when a method implemented on the Mininet-WiFi source code is evoked by the CLI, the prefix _py_ must always be used. In addition to `setPosition()`, other methods will be demonstrated throughout this book. 394 | 395 | 396 | Now, let us check the newly defined position. 397 | 398 | ``` 399 | mininet-wifi> py sta1.position 400 | [10.0, 0.0, 0.0] 401 | ``` 402 | 403 | In this case, the position is defined as: x=10, y=0 and z=0. 404 | 405 | 406 | Various other data about a particular node can be obtained using the generic form _node.params_ or _node.wintfs_, as shown below. 407 | 408 | ``` 409 | mininet-wifi> py sta1.params 410 | {'wlan': ['sta1-wlan0'], 'ip': '10.0.0.1/8', 'ip6': '2001:0:0:0:0:0:0:1/64', 'channel': 1, 'mode': 'g'} 411 | mininet-wifi> py sta1.wintfs 412 | {0: } 413 | ``` 414 | 415 | Now, you can filter the desired information as follows. 416 | 417 | ``` 418 | mininet-wifi> py sta1.wintfs[0].freq 419 | 2.412 420 | mininet-wifi> py sta1.wintfs[0].mode 421 | g 422 | mininet-wifi> py sta1.wintfs[0].txpower 423 | 14 424 | mininet-wifi> py sta1.wintfs[0].range 425 | 62 426 | mininet-wifi> py sta1.wintfs[0].antennaGain 427 | 5 428 | ``` 429 | 430 | _wintfs[0]_ means that the information to be obtained comes from the first wireless interface. If the node has multiple interfaces, _wintfs[n]_ - e.g. _wintfs[1]_ to indicate the second interface and so on - can also be used. 431 | 432 | 433 | ## OVSAP _versus_ UserAP 434 | 435 | Mininet-WiFi supports two types of access points that differ basically in the location where they are run. _OVSAP_ or _OVSKernelAP_ runs in the kernel space of the operating system, whereas the _UserAP_ is executed in the user space. Additionally, you may prefer one over the other due to possible advantages, such as supported features and performance. 436 | 437 | 438 | For example, some features may be supported by one and not by another. Until recently, _OVSAP_ did not support _meter tables_, a type of table belonging to the OpenFlow protocol that is responsible for Quality of Service (QoS)-related operations, which was included in version 1.3 of this protocol. On the other hand, _UserAP_ already supported it by then. 439 | 440 | 441 | Another important issue is the possibility of running switches or access points in particular _network namespaces_. In this case, _OVS_ does not support this feature natively yet, unlike _UserAP_, which supports it. What does that mean? Try using the following command. 442 | 443 | ``` 444 | ~/mininet-wifi$ sudo mn --wifi 445 | ``` 446 | 447 | It allows you to view the interfaces of the **ap1** access point. 448 | 449 | ``` 450 | mininet-wifi> ap1 ip link 451 | 1: lo: mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000 452 | link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 453 | 2: enp2s0: mtu 1500 qdisc fq_codel state DOWN mode DEFAULT group default qlen 1000 454 | link/ether 84:7b:eb:fc:63:1a brd ff:ff:ff:ff:ff:ff 455 | 3: wlp1s0: mtu 1500 qdisc noqueue state UP mode DORMANT group default qlen 1000 456 | link/ether f8:da:0c:95:12:d3 brd ff:ff:ff:ff:ff:ff 457 | 4: docker0: mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default 458 | link/ether 02:42:04:ed:bc:24 brd ff:ff:ff:ff:ff:ff 459 | 5: br-7e51375c6c71: mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default 460 | link/ether 02:42:6f:43:07:ee brd ff:ff:ff:ff:ff:ff 461 | 6: hwsim0: mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 462 | link/ieee802.11/radiotap 12:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff 463 | 9: ap1-wlan1: mtu 1500 qdisc tbf master ovs-system state UP mode DEFAULT group default qlen 1000 464 | link/ether 02:00:00:00:02:00 brd ff:ff:ff:ff:ff:ff 465 | 10: ovs-system: mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 466 | link/ether ee:99:70:bb:39:89 brd ff:ff:ff:ff:ff:ff 467 | 11: ap1: mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 468 | link/ether 0a:94:5d:2c:8b:40 brd ff:ff:ff:ff:ff:ff 469 | ``` 470 | 471 | Note that a large number of network interfaces can be viewed, including those that, in practice, do not integrate the **ap1** access point, such as the wireless and wired interfaces of the computer running Mininet-WiFi. This is the behavior observed when _OVS_, the default type of switch or access point for Mininet-WiFi, is being used. 472 | 473 | 474 | Now, let us look at how _UserAP_ behaves. To do so, run the following command. 475 | 476 | ``` 477 | ~/mininet-wifi$ sudo mn --wifi --ap user --innamespace 478 | ``` 479 | 480 | info The `--innamespace` parameter was not used with OVS because it does not support this command yet. `--innamespace` is responsible for making the node run in its own _network namespace_, instead of the root network namespace. 481 | 482 | After that, check the interfaces of the **ap1** access point. 483 | 484 | ``` 485 | mininet-wifi> ap1 ip link 486 | 1: lo: mtu 65536 qdisc noop state DOWN mode DEFAULT group default qlen 1000 487 | link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 488 | 2: ap1-eth0@if46: mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000 489 | link/ether de:93:af:2c:68:a0 brd ff:ff:ff:ff:ff:ff link-netnsid 0 490 | 45: ap1-wlan1: mtu 1500 qdisc tbf state UP mode DEFAULT group default qlen 1000 491 | link/ether 02:00:00:00:02:00 brd ff:ff:ff:ff:ff:ff 492 | ``` 493 | 494 | As you can realize, the number of network interfaces has dropped considerably. The loopback interface was expected to appear among the results, in addition to the **ap1-wlan1** interface, which is the wireless interface of the **ap1** access point. The only interface that could be considered as unexpected would be the **ap1-eth0** interface, which is the interface used to connect to the SDN controller. 495 | 496 | 497 | Another relevant issue between _OVSAP_ and _UserAP_ is the performance. _UserAP_'s performance has significantly worsened since the releases of the newer versions of the Linux kernel. The reason? We confess not to have an answer to this question. However, we invite you to check this issue in practice. 498 | 499 | 500 | The following command will run Mininet with _OVS_ and test the throughput between nodes **h1** and **h2**. 501 | 502 | ``` 503 | ~/mininet-wifi$ sudo mn --test iperf 504 | *** Iperf: testing TCP bandwidth between h1 and h2 505 | *** Results: ['40.1 Gbits/sec', '40.0 Gbits/sec'] 506 | ``` 507 | 508 | The following command runs Mininet with _UserSwitch_ and measures the throughput between the same nodes, **h1** and **h2**. 509 | 510 | ``` 511 | ~/mininet-wifi$ sudo mn --switch=user --test iperf 512 | *** Iperf: testing TCP bandwidth between h1 and h2 513 | *** Results: ['171 Mbits/sec', '172 Mbits/sec'] 514 | ``` 515 | 516 | info If you are not able to execute the previous command, you need to start an SDN controller on another terminal and replace `--test iperf` by `--controller=remote`. Then, after starting the controller, run _iperf_ on the Mininet-WiFi CLI as follows: `iperf h1 h2`. 517 | 518 | You may be wondering: why _UserSwitch_? _UserAP_ has been extended from Mininet's _UserSwitch_. So in practice, they are the same switch or access point. But back to the result, did you notice the difference between them? _UserSwitch_ has much lower performance compared to OVS. 519 | 520 | 521 | With respect to _UserAP_ still, an example of its implementation is _Basic OpenFlow Software Switch_ (BOFUSS), a successor of [ofsoftswitch13](https://github.com/CPqD/ofsoftswitch13). It has been employed in several studies and you may definitely want to use it at some point. _BOFUSS_ promises to eliminate most performance-related issues. 522 | 523 | 524 | info To install _BOFUSS_, just run `sudo util/install.sh -3f` from Mininet-WiFi's root directory. 525 | 526 | ## Graphical User Interface (GUI) 527 | For those who do not know _Python_ or are new to Mininet-WiFi, currently there are two options for creating scripts in _Python_ with the support of graphic interfaces: by using _Visual Network Descriptor (VND)_ or _MiniEdit_. 528 | 529 | ### Visual Network Descriptor 530 | 531 | Requirements: web server, php, flash player, visual network descriptor 532 | 533 | _Visual Network Descriptor_, or simply VND, is a tool created for a master's work that is able to generate _Python_ scripts for Mininet-WiFi via a web browser. Written predominantly in the _Flex_ programming language, VND also includes some instructions in PHP and XML. 534 | 535 | 536 | Using VND is relatively simple. First you need to make a clone of its [source code](https://github.com/ramonfontes/vnd), and follow the installation steps available on the source code page. In general terms, you must have a web server, PHP and Flash Player installed. Then just access it through your preferred web browser. If all goes well, a screen similar to the one shown in the figure below should appear. 537 | 538 | ![Visual Network Descriptor](figures/vnd.png "Visual Network Descriptor") 539 | 540 | With VND open, you can use the mouse cursor to select the nodes that you want to include in the topology and their respective connections. You can also create settings for nodes and save the topology for later use. To generate scripts for Mininet-WiFi, just follow the _File->Export->Export to Mininet-WiFi menu. A standard file with a .sh extension will be created; it consists of _Python_ statements and can be executed as if it were a _Python_ file. 541 | 542 | 543 | For example, a script named <_mytopology.sh_> can be executed as follows. 544 | 545 | ``` 546 | ~/mininet-wifi$ sudo python mytopology.sh 547 | ``` 548 | 549 | video 550 | 551 | [Visual Network Descriptor](https://youtu.be/KsoRMnDP_PA) 552 | 553 | 554 | ### MiniEdit 555 | 556 | Requirements: scripts only 557 | 558 | Another alternative for creating topologies with graphics support is _MiniEdit_. Written in _Python_, _MiniEdit_ was initially developed for Mininet and has been constantly upgraded to work with Mininet-WiFi. The goal of _MiniEdit_'s developers is to make all the features supported by Mininet-WiFi available on _MiniEdit_. 559 | 560 | 561 | _MiniEdit_ has a fairly simple user interface that features a screen with a line of tool icons on the left side of the window and a menu bar at the top. It comes already included in the Mininet-WiFi source code. 562 | 563 | 564 | To use it, just run <_examples/miniedit.py_>. 565 | 566 | ``` 567 | ~/mininet-wifi$ sudo python examples/miniedit.py 568 | ``` 569 | 570 | ![Miniedit](figures/miniedit.png "Miniedit") 571 | 572 | 573 | After you run it, a screen similar to the one shown in the figure above should appear. With it you can add nodes supported by Mininet-WiFi and their respective settings, in addition to their links, of course. In the current version of _MiniEdit_, different types of scenarios are already supported, for example: _ad hoc_ and _mesh_ networks, _WiFi-Direct_, Radius protocol, WPA, among other environments. 574 | 575 | 576 | You might ask: what is the best alternative to work with GUI? _MiniEdit_ or VND? You may want to use _MiniEdit_, since it is a part of Mininet-WiFi. There is also a tendency for VND to be gradually discontinued. 577 | 578 | video 579 | 580 | [MiniEdit and Mininet-WiFi](https://youtu.be/j4JS4xxCrCA) 581 | 582 | 583 | ### Viewing 2D and 3D graphics 584 | Viewing topologies by means of graphics is another feature that can be used in Mininet-WiFi. You can generate both 2D and 3D graphics. Nevertheless, there are situations where 3D graphics are very useful, such as surveys involving drones and satellites, since the representation of different levels of altitudes may be necessary. 585 | 586 | 587 | Thus, given its importance, we will then understand how it is possible to generate 2D and 3D graphics on Mininet-WiFi. Initially we will learn to create the two types of graphics (2D and 3D) using the CLI.\\ 588 | 589 | The command below will generate a 2D topology. 590 | 591 | ``` 592 | ~/mininet-wifi$ sudo mn --wifi --plot --position 593 | ``` 594 | 595 | While the following command will generate a 3D topology. 596 | 597 | ``` 598 | ~/mininet-wifi$ sudo mn --wifi --plot3d --position 599 | ``` 600 | 601 | All scripts available in the <_/examples_> directory - a Mininet-WiFi directory where you can find a wide variety of ready-to-run scripts - generate 2D graphics. If you choose to generate 3D graphics, simply make a small change in the code. 602 | 603 | 604 | For example, let us take as an example <_position.py_>, available in the <_/examples_> directory. This file contains the following content: 605 | 606 | ``` 607 | net.plotGraph(max_x=100, max_y=100) 608 | ``` 609 | 610 | As can be seen, only the _x_ and _y_ axes were defined and the resulting graph will be somewhat similar to the one shown below. Therefore, to generate 3D graphics, simply add the _z_ axis, which will produce something similar to what was shown in below. 611 | 612 | ![2D Graphic](figures/2d.png "2D Graphic") 613 | 614 | ![3D Graphic](figures/3d.png "3D Graphic") 615 | 616 | 617 | ``` 618 | net.plotGraph(max_x=100, max_y=100, max_z=100) 619 | ``` 620 | 621 | Optionally, minimum values for _x_, _y_ and _z_ axes can also be defined. 622 | 623 | ``` 624 | net.plotGraph(min_x=10, min_y=10, min_z=10, max_x=100, max_y=100, max_z=100) 625 | ``` 626 | 627 | info Graphics generated by Mininet-WiFi are supported by _matplotlib_, a data visualization library available in the _Python_ programming language. 628 | 629 | video 630 | 631 | [Building 3D Graphic](https://youtu.be/lMkIV0YBTss) 632 | 633 | 634 | ## Wireless network emulation 635 | Wireless media emulation in Mininet-WiFi can be done in two ways: with [TC](https://en.wikipedia.org/wiki/Tc_(Linux)) or [Wmediumd](https://github.com/ramonfontes/wmediumd/). Let us then understand how to use them and what are the differences between them. 636 | 637 | ### TC (_Traffic Control_) 638 | If Mininet-WiFi is running, quit it. Then start it again with the following command: 639 | 640 | ``` 641 | ~/mininet-wifi$ sudo mn --wifi --position 642 | ``` 643 | 644 | Now, view the TC information on the Mininet-WiFi CLI: 645 | 646 | ``` 647 | mininet-wifi> ap1 tc qdisc 648 | qdisc noqueue 0: dev lo root refcnt 2 649 | qdisc pfifo_fast 0: dev enp2s0 root refcnt 2 bands 3 650 | priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1 651 | qdisc noqueue 0: dev wlp1s0 root refcnt 2 652 | qdisc noqueue 0: dev docker0 root refcnt 2 653 | qdisc tbf 2: dev ap1-wlan1 root refcnt 5 rate 54Mbit burst 14998b lat 1.0ms 654 | qdisc pfifo 10: dev ap1-wlan1 parent 2:1 limit 1000p 655 | ``` 656 | 657 | The output that interests us is highlighted below: 658 | 659 | ``` 660 | qdisc tbf 2: dev ap1-wlan1 root refcnt 5 661 | rate 54Mbit burst 14998b lat 1.0ms 662 | ``` 663 | 664 | In general terms, this output instructs **ap1** to limit the bandwidth to up to 54 Mbits/s, which represents the maximum value that the IEEE 802.11g standard can nominally support. With this information it is easier to understand how TC works. 665 | 666 | 667 | Considering that TC values are applied to stations and also that propagation models are supported by Mininet-WiFi, for a distance _d_ between access point and station, there is always a received signal value, which can vary with the chosen propagation model. Then, as the node is moving to a new position, a new value for _d_ is calculated and from this we obtain the received signal and the bandwidth value that will be applied by TC to the wireless interface of the node. 668 | 669 | 670 | In practice, the value applied by TC to **ap1** does not change; instead, the values applied to the interfaces of the stations change. Thus, in an infrastructure environment we will always have two reference points for the calculation of _d_: the station and the access point. Two stations may be associated with the same access point, and different bandwidth values can be assigned to their interfaces: one for **sta1** and another for **sta2**. 671 | 672 | 673 | Now let us imagine a wireless ad hoc network with three stations. As a wireless network, we can say that this network consists of a non-infrastructure environment, which means that this topology does not have a central node, i.e. the access point. In this type of network the three stations can associate with each other, where, for example, **sta1** can maintain association with **sta2** and **sta3**. However, they only have one wireless interface, and thus are particularly difficult to control using TC. 674 | 675 | 676 | What would be the reference point to calculate _d_ for **sta1**, **sta2** or **sta3**? Differently from an infrastructure network, where we have two reference points for the calculation of _d_ - station and access point -, in a non-infrastructure network this does not occur. Thus, wireless _adhoc_ and _mesh_, require the use of _Wmediumd_, which implements an ideal wireless medium simulator for these types of networks. 677 | 678 | ### Wmediumd 679 | 680 | The module responsible for virtualizing WiFi network cards on Mininet-WiFi, mac80211\_hwsim, uses the same virtual medium for all its wireless nodes. This means that all nodes are internally within reach of each other and can be discovered by scanning, as we have done with _iw_ previously. If the wireless interfaces need to be isolated from each other, the use of _Wmediumd_ is recommended. 681 | 682 | 683 | [Wmediumd](https://github.com/jlopex/mac80211_hwsim) had been developed since 2011, but only in 2017 it was integrated into Mininet-WiFi thanks to [Patrick Große](https://github.com/patgrosse), the developer responsible for creating the first _Wmediumd_ extension for Mininet-WiFi. 684 | 685 | 686 | Unlike TC, which limits the bandwidth available to the interface, _Wmediumd_ relies on a [signal table](https://github.com/ramonfontes/wmediumd/blob/mininet-wifi/tests/signal_table_ieee80211ax) and manages the isolation of the interfaces in real time as data travels across the network. 687 | 688 | ### TC _versus Wmediumd in practice 689 | 690 | Start Mininet-WiFi with the following command. 691 | 692 | ``` 693 | ~/mininet-wifi$ sudo mn --wifi --topo single,3 --position --plot 694 | ``` 695 | 696 | This command will create three stations that will associate themselves with access point **ap1**. The `--plot` parameter will open a topology graph. More details on this parameter will be seen later. 697 | 698 | 699 | Now, check the signal strength perceived by **sta1** in relation to the **ap1** access point by running the `scan` command. 700 | 701 | ``` 702 | mininet-wifi> sta1 iw dev sta1-wlan0 scan 703 | BSS 02:00:00:00:03:00(on sta1-wlan0) -- associated 704 | TSF: 1536705774286475 usec (17785d, 22:42:54) 705 | freq: 2412 706 | beacon interval: 100 TUs 707 | capability: ESS ShortSlotTime (0x0401) 708 | signal: -36.00 dBm 709 | last seen: 0 ms ago 710 | Information elements from Probe Response frame: 711 | SSID: my-ssid 712 | Supported rates: 1.0* 2.0* 5.5* 11.0* 6.0 9.0 12.0 18.0 713 | DS Parameter set: channel 1 714 | ERP: Barker_Preamble_Mode 715 | Extended supported rates: 24.0 36.0 48.0 54.0 716 | Extended capabilities: 717 | * Extended Channel Switching 718 | * Operating Mode Notification 719 | ``` 720 | 721 | Also check the RSSI using the _wintfs_ option: 722 | 723 | ``` 724 | mininet-wifi> py sta1.wintfs[0].rssi 725 | -66.0 726 | ``` 727 | 728 | As you can see, there is a difference in the signals received by the `iw scan` and _wintfs_ options. With `iw` the received signal was -36 dBm, whereas using _wintfs_ it was -66 dBm. While TC is in use, it will not be possible to get any updated information about the signal strength, or any other data that depends on it, by using network commands, such as _iw_. Perhaps one of the few useful data to verify is whether the station **sta1** is in fact associated with the access point **ap1**. 729 | 730 | 731 | The `iw link` command can also be used for this, as follows. 732 | 733 | ``` 734 | mininet-wifi> sta1 iw dev sta1-wlan0 link 735 | Connected to 02:00:00:00:03:00 (on sta1-wlan0) 736 | SSID: my-ssid 737 | freq: 2412 738 | RX: 12486 bytes (236 packets) 739 | TX: 805 bytes (9 packets) 740 | signal: -36 dBm 741 | tx bitrate: 18.0 MBit/s 742 | 743 | bss flags: short-slot-time 744 | dtim period: 2 745 | beacon int: 100 746 | ``` 747 | 748 | Now let us move **sta1** and test the received signal again by performing a new scan. 749 | 750 | ``` 751 | mininet-wifi> py sta1.setPosition('250,250,0') 752 | mininet-wifi> sta1 iw dev sta1-wlan0 scan 753 | BSS 02:00:00:00:03:00(on sta1-wlan0) 754 | TSF: 1536706071142532 usec (17785d, 22:47:51) 755 | freq: 2412 756 | beacon interval: 100 TUs 757 | capability: ESS ShortSlotTime (0x0401) 758 | signal: -36.00 dBm 759 | last seen: 0 ms ago 760 | Information elements from Probe Response frame: 761 | SSID: my-ssid 762 | Supported rates: 1.0* 2.0* 5.5* 11.0* 6.0 9.0 12.0 18.0 763 | DS Parameter set: channel 1 764 | ERP: Barker_Preamble_Mode 765 | Extended supported rates: 24.0 36.0 48.0 54.0 766 | Extended capabilities: 767 | * Extended Channel Switching 768 | * Operating Mode Notification 769 | ``` 770 | 771 | Surprisingly, the signal remained the same as before, even when changing the position of **sta1**. In fact, **ap1** should not even appear in the scan, as **sta1**) is no longer under the signal coverage of access point **ap1**. This shows that the TC really does not perceive the wireless medium, since even when the station is no longer within the signal coverage of the **ap1** access point, it is still capable of seeing it. 772 | 773 | 774 | Now, let us repeat what we did earlier by using _Wmediumd_. 775 | 776 | ``` 777 | ~/mininet-wifi$ sudo mn --wifi --topo single,3 --link=wmediumd --position --plot 778 | ``` 779 | 780 | Then we perform the scan from **sta1**, change its position and repeat the scan. 781 | 782 | ``` 783 | mininet-wifi> sta1 iw dev sta1-wlan0 scan 784 | BSS 02:00:00:00:03:00(on sta1-wlan0) -- associated 785 | TSF: 1536709235310507 usec (17785d, 23:40:35) 786 | freq: 2412 787 | beacon interval: 100 TUs 788 | capability: ESS ShortSlotTime (0x0401) 789 | signal: -67.00 dBm 790 | last seen: 0 ms ago 791 | Information elements from Probe Response frame: 792 | SSID: my-ssid 793 | Supported rates: 1.0* 2.0* 5.5* 11.0* 6.0 9.0 12.0 18.0 794 | DS Parameter set: channel 1 795 | ERP: Barker_Preamble_Mode 796 | Extended supported rates: 24.0 36.0 48.0 54.0 797 | Extended capabilities: 798 | * Extended Channel Switching 799 | * Operating Mode Notification 800 | mininet-wifi> py sta1.setPosition('250,250,0') 801 | mininet-wifi> sta1 iw dev sta1-wlan0 scan 802 | ``` 803 | 804 | As you can see, the signal strength perceived by **sta1** was initially -67 dBm. However, when it went out of the signal range of access point **ap1**, there was a predicted change in the result. In addition to returning an expected signal value at the first moment, in the second the **ap1** access point could not be reached, since **ap1** was not able to reach **sta1** anymore. 805 | 806 | warning Using _wintfs_ with _Wmediumd_ is not recommended since some implementations of the latter for the calculation of the received signal were not transferred to Mininet-WiFi. In this case, it is always preferable to use _iw_ or _iwconfig_. 807 | 808 | ## Propagation model 809 | Propagation models are mathematical models typically used by simulators and wireless network emulators to try to mimic the behavior of a wireless medium. In the literature, several propagation models have been proposed in order to support the different features of wireless media, such as varied environment types (indoor and outdoor), signal attenuation, interference, etc. 810 | 811 | 812 | Mininet-WiFi currently supports the following propagation models: _Friis Propagation Loss Model_, _Log-Distance Propagation Loss Model_ (default), _Log-Normal Shadowing Propagation Loss Model_, _International Telecommunication Union (ITU) Propagation Loss Model_ and _Two-Ray Ground Propagation Loss Model_. 813 | 814 | 815 | The correct choice of propagation model makes a big difference. For example, one of the variables used in propagation models is the exponent. The exponent is variable that will instruct the propagation model as to the testing environment, i.e. whether it is an indoor or outdoor environment, or whether it is an interference-free environment or not. 816 | 817 | 818 | Specifying a propagation model is a simple task. The various Mininet-WiFi sample scripts will certainly support this task, especially <_propagationModel.py_>. In it you can find the function responsible for defining the propagation model and its parameters. 819 | 820 | 821 | To demonstrate how the propagation model can affect the configuration of the nodes that make up the network, we will execute the following script. 822 | 823 | ``` 824 | ~/mininet-wifi$ sudo python examples/propagationModel.py 825 | ``` 826 | 827 | Using the pre-defined propagation model, we can observe that the signal strength perceived by **sta1** was around -79 dBm. 828 | 829 | ``` 830 | mininet-wifi> py sta1.wintfs[0].rssi 831 | -79.0 832 | ``` 833 | 834 | On the other hand, after configuring the _free space_ propagation model, the signal strength increased to approximately -47 dBm. If you did not find the -79 dBm and -47 dBm values, do not worry. What matters is the value obtained after setting up the propagation model. This should be higher than the previously noted values. 835 | 836 | 837 | The propagation model can be modified as follows: 838 | 839 | 840 | from: 841 | ``` 842 | net.setPropagationModel(model="logDistance", exp=4) 843 | ``` 844 | 845 | to: 846 | ``` 847 | net.setPropagationModel(model="friis") 848 | ``` 849 | 850 | Then, check the RSSI after running the modified script. 851 | 852 | ``` 853 | mininet-wifi> py sta1.wintfs[0].rssi 854 | -47.0 855 | ``` 856 | 857 | Another relevant change you can see is related to the range of the access point. Certainly the new range of access point **ap1** is now much larger than the previously observed one. 858 | 859 | 860 | info <_propagationModel.py_> does not use _Wmediumd_, so if it is necessary to obtain the signal strength it should always be obtained using the _wintfs_ command. 861 | 862 | The new signal range value evidences the importance of choosing the correct propagation model for the scenario on which it is necessary to work. The new signal strength, which is higher than the previous one, also shows the behavior of the _free space_ propagation model, since _free space_ does not take into account any kind of interference or barrier that could attenuate the signal. 863 | 864 | It is important to note that in addition to the exponent discussed above, there are other parameters that may be unique or not in relation to each model. You can find more information about the supported models and their parameters on Mininet-WiFi's [web page](http://mininet-wifi.github.io/). 865 | 866 | ### Providing more realism 867 | Some propagation models have no signal variation over time. This means that if we check the signal strength of a particular node, the perceived signal strength will always be the same. However, as we all know, the wireless medium is not constant and many factors can affect the perceived signal strength. 868 | 869 | 870 | Therefore, in cases where the variation in signal strength is important and you need to represent what happens in the real world with greater fidelity, it is necessary to set up the _fading\_coefficient_, which produces signal attenuation over time. 871 | 872 | 873 | To check the effect caused by _fading_ in practice, let us run the following code. 874 | 875 | ``` 876 | ~/mininet-wifi$ sudo python examples/wmediumd_interference.py 877 | ``` 878 | 879 | Now we are able to verify the signal strength variation perceived by a given station through _iw_, as below. Notice that as <_wmediumd\_interference.py_> uses _Wmediumd_, the signal strength can be obtained by running either _iw_ or _iwconfig_. 880 | 881 | ``` 882 | mininet-wifi> sta1 iw dev sta1-wlan0 link 883 | Connected to 02:00:00:00:03:00 (on sta1-wlan0) 884 | SSID: new-ssid 885 | freq: 5180 886 | RX: 6901 bytes (124 packets) 887 | TX: 712 bytes (8 packets) 888 | signal: -65 dBm 889 | tx bitrate: 12.0 MBit/s 890 | 891 | bss flags: short-slot-time 892 | dtim period: 2 893 | beacon int: 100 894 | 895 | mininet-wifi> sta1 iw dev sta1-wlan0 link 896 | Connected to 02:00:00:00:03:00 (on sta1-wlan0) 897 | SSID: new-ssid 898 | freq: 5180 899 | RX: 8827 bytes (165 packets) 900 | TX: 800 bytes (9 packets) 901 | signal: -62 dBm 902 | tx bitrate: 12.0 MBit/s 903 | 904 | bss flags: short-slot-time 905 | dtim period: 2 906 | beacon int: 100 907 | ``` 908 | 909 | As you can see, the signal strength perceived by **sta1** was initially -65 dBm and then switched to -62 dBm later on. This variation is expected to happen whenever the received signal level is checked. This is a variation that occurs in a random fashion while also respecting the interval defined by the _fading_ parameter. 910 | 911 | infoTry changing the _fading_ value and check the result. The higher the _fading_ value, the greater the signal variation. 912 | 913 | warning All propagation models supported by Mininet-WiFi can be found in <_mn\_wifi/propagationModels.py_>. Should you want to implement new propagation models, you will need to include them in this file. 914 | 915 | ## Distance _versus_ received signal 916 | In addition to the throughput, the distance variation will also impact the signal strength received from the nodes. Obviously, the more distant the source and destination are, the worse the perceived signal should be. This is due to signal attenuation. 917 | 918 | 919 | We have already seen in https://github.com/ramonfontes/mn-wifi-ebook/blob/main/beginner.md#first-steps-to-use-mininet-wifi how we can visualize the signal strength perceived by a node. Let us use, then, the same command to observe the perceived signal strength from different positions. To do so, run <_wmediumd\_interference.py_>. 920 | 921 | ``` 922 | ~/mininet-wifi$ sudo python examples/wmediumd_interference.py 923 | ``` 924 | 925 | Then check the received signal. 926 | 927 | ``` 928 | mininet-wifi> sta1 iw dev sta1-wlan0 link 929 | Connected to 02:00:00:00:03:00 (on sta1-wlan0) 930 | SSID: new-ssid 931 | freq: 5180 932 | RX: 9142 bytes (184 packets) 933 | TX: 88 bytes (2 packets) 934 | signal: -64 dBm 935 | tx bitrate: 6.0 MBit/s 936 | 937 | bss flags: short-slot-time 938 | dtim period: 2 939 | beacon int: 100 940 | ``` 941 | 942 | Now, let us use the `distance` command to view the distance between **sta1** and **ap1**. 943 | 944 | ``` 945 | mininet-wifi> distance sta1 ap1 946 | The distance between sta1 and ap1 is 11.18 meters 947 | ``` 948 | 949 | As you can see, the distance between them is just over 11 meters, and the signal level perceived by **sta1** was -64 dBm. So let us change the position of **sta1** in order to reduce the distance from access point **ap1** and check again the signal strength received by **sta1**. 950 | 951 | ``` 952 | mininet-wifi> py sta1.setPosition('40,40,0') 953 | mininet-wifi> distance sta1 ap1 954 | The distance between sta1 and ap1 is 26.93 meters 955 | mininet-wifi> sta1 iw dev sta1-wlan0 link 956 | Connected to 02:00:00:00:03:00 (on sta1-wlan0) 957 | SSID: new-ssid 958 | freq: 5180 959 | RX: 176746 bytes (4379 packets) 960 | TX: 1668 bytes (19 packets) 961 | signal: -79 dBm 962 | tx bitrate: 18.0 MBit/s 963 | 964 | bss flags: short-slot-time 965 | dtim period: 2 966 | beacon int: 100 967 | ``` 968 | 969 | We can see that after changing the position, the distance increased and consequently the signal level decreased from -64 dBm to -79 dBm. This may be a simple and obvious conclusion; however, the steps we have just taken aid greatly in the teaching and learning process. 970 | 971 | 972 | - Ramon dos Reis Fontes, Mohamed Mahfoudi, Walid Dabbous, Thierry Turletti, Christian Esteve Rothenberg. _How far can we go? Towards Realistic Software-Defined Wireless Networking Experiments. In The Computer Journal (Special Issue on Software Defined Wireless Networks), 2017. 973 | 974 | 975 | 976 | ## Modifying _bitrate_ 977 | 978 | _Bitrate_ refers to the rate of data transmission supported for a given moment. Wi-Fi devices are able to adjust their Modulation and Coding Scheme according to the received signal level. In practice, the more complex the modulation scheme is, the more bits can be transmitted. In contrast, they also become more sensitive to interference and noise, and hence require a cleaner channel. 979 | 980 | 981 | We will use _iw_ to modify bit rates. To do so, consider using <_wmediumd\_interference.py_> one more time. 982 | 983 | ``` 984 | ~/mininet-wifi$ sudo python examples/wmediumd_interference.py 985 | ``` 986 | 987 | Next, let us do some simple tests and note the difference in the bandwidth values obtained for different bitrates. 988 | 989 | 990 | First, run _iperf_ without changing the bitrate values. 991 | 992 | ``` 993 | mininet-wifi> iperf sta1 sta2 994 | *** Iperf: testing TCP bandwidth between sta1 and sta2 995 | *** Results: ['14.3 Mbits/sec', '14.4 Mbits/sec'] 996 | ``` 997 | 998 | Then look at the current bitrate. As you can see below, the bitrate value was 54 Mbits/s. 999 | 1000 | ``` 1001 | mininet-wifi> sta1 iw dev sta1-wlan0 link 1002 | Connected to 02:00:00:00:03:00 (on sta1-wlan0) 1003 | SSID: new-ssid 1004 | freq: 5180 1005 | RX: 581186 bytes (7475 packets) 1006 | TX: 19278284 bytes (12610 packets) 1007 | signal: -64 dBm 1008 | tx bitrate: 54.0 MBit/s 1009 | 1010 | bss flags: short-slot-time 1011 | dtim period: 2 1012 | beacon int: 100 1013 | ``` 1014 | 1015 | Now, change the bitrate and re-measure the bandwidth. 1016 | 1017 | ``` 1018 | mininet-wifi> sta1 iw dev sta1-wlan0 set bitrates legacy-5 6 9 1019 | mininet-wifi> iperf sta1 sta2 1020 | *** Iperf: testing TCP bandwidth between sta1 and sta2 1021 | *** Results: ['5.87 Mbits/sec', '5.93 Mbits/sec'] 1022 | mininet-wifi> sta1 iw dev sta1-wlan0 link 1023 | Connected to 02:00:00:00:03:00 (on sta1-wlan0) 1024 | SSID: new-ssid 1025 | freq: 5180 1026 | RX: 840551 bytes (12506 packets) 1027 | TX: 23301226 bytes (15251 packets) 1028 | signal: -64 dBm 1029 | tx bitrate: 9.0 MBit/s 1030 | 1031 | bss flags: short-slot-time 1032 | dtim period: 2 1033 | beacon int: 100 1034 | ``` 1035 | 1036 | Note that the bitrate was limited to 9 Mbits/s and the measurement from _iperf_ dropped to less than 6 Mbits/s. 1037 | 1038 | 1039 | Finally, let us make another bitrate change and measure the bandwidth once more. 1040 | 1041 | ``` 1042 | mininet-wifi> sta1 iw dev sta1-wlan0 set bitrates legacy-5 6 1043 | mininet-wifi> iperf sta1 sta2 1044 | *** Iperf: testing TCP bandwidth between sta1 and sta2 1045 | *** Results: ['4.37 Mbits/sec', '4.44 Mbits/sec'] 1046 | mininet-wifi> sta1 iw dev sta1-wlan0 link 1047 | Connected to 02:00:00:00:03:00 (on sta1-wlan0) 1048 | SSID: new-ssid 1049 | freq: 5180 1050 | RX: 1044693 bytes (16503 packets) 1051 | TX: 26353234 bytes (17256 packets) 1052 | signal: -64 dBm 1053 | tx bitrate: 6.0 MBit/s 1054 | 1055 | bss flags: short-slot-time 1056 | dtim period: 2 1057 | beacon int: 100 1058 | ``` 1059 | 1060 | Once again the available bandwidth dropped and the _bitrate_ was limited to 6 Mbits/s, as defined by the command. 1061 | 1062 | 1063 | Another interesting test is to verify the difference in the transfer rate supported by different Wi-Fi standards. For example, since the script is configured to operate on the IEEE 802.11a standard, which supports up to 54 Mbits/s, it was possible to get the 14 Mbits/s acquired in the previous test. On the other hand, another standard, IEEE 802.11b, would support only up to 11 Mbits/s. 1064 | 1065 | 1066 | Let us carry out a simple test: change the operating mode of the script from _mode='a'_ to _mode='b'_, and change the channel from 36 to 1. Then run _iperf_ one more time and observe the result. 1067 | 1068 | warning Due to a lack of knowledge, many users end up making mistakes when they configure the channel on an access point. What happens is that, for example, channel one does not work at 5 GHz, the frequency used in the IEEE 802.11a standard. You cannot, thus, use channel strips that are not compatible with certain 802.11 standards. The document available on [hostapd](https://w1.fi/cgit/hostap/plain/hostapd/hostapd.conf) can serve as a good reference point to identify the correct channels for certain operating standards. 1069 | 1070 | ``` 1071 | mininet-wifi> iperf sta1 sta2 1072 | *** Iperf: testing TCP bandwidth between sta1 and sta2 1073 | *** Results: ['4.50 Mbits/sec', '4.57 Mbits/sec'] 1074 | ``` 1075 | 1076 | As you can see, the measured bandwidth was 4.5 Mbits/s, which is limited to 11 Mbits/s, exactly as defined by the IEEE 802.11b standard. 1077 | 1078 | ## Distance _versus_ throughput 1079 | 1080 | Throughput is the ability to transmit data from one network point to another over a period of time, determining the speed at which data travels through a link. In wireless networks, throughput is, in theory, highly impacted by the distance between two nodes. 1081 | 1082 | Among the tools for measuring throughput, _iperf_ is certainly the one that stands out the most, as it is the preferred tool in most cases. Throughput measurement using _iperf_ is relatively simple, since two nodes executing it are enough for it to function, with one of the nodes operating as client and the other as server. 1083 | 1084 | 1085 | In order to run _iperf_ to verify the relation between distance and bandwidth, we will use the <_position.py_> file as a basis. 1086 | 1087 | ``` 1088 | ~/mininet-wifi$ sudo python examples/position.py 1089 | ``` 1090 | 1091 | After running it, you will see a topology with two stations and one access point. 1092 | 1093 | 1094 | Since the script file has been successfully executed, let us measure the throughput between **sta1** and **sta2** according to their initial arrangement. 1095 | 1096 | ``` 1097 | mininet-wifi> iperf sta1 sta2 1098 | *** Iperf: testing TCP bandwidth between sta1 and sta2 1099 | *** Results: ['8.42 Mbits/sec', '9.04 Mbits/sec'] 1100 | ``` 1101 | 1102 | Keep a record of the result observed in this test round. _The result may suffer slight variations_. 1103 | 1104 | 1105 | Now, we will change the positions of **sta1** and **sta2** so that they are further away from access point **ap1**. Then we will measure the throughput between **sta1** and **sta2** again. 1106 | 1107 | ``` 1108 | mininet-wifi> py sta1.setPosition('40,90,0') 1109 | mininet-wifi> py sta2.setPosition('60,10,0') 1110 | mininet-wifi> iperf sta1 sta2 1111 | *** Iperf: testing TCP bandwidth between sta1 and sta2 1112 | *** Results: ['6.98 Mbits/sec', '7.14 Mbits/sec'] 1113 | ``` 1114 | 1115 | Comparing this new result with the previous one, it is clear that the more distant the stations are from the access point, the smaller the throughput tends to be. 1116 | 1117 | infoIn Mininet-WiFi, the `iperf sta1 sta2` command automatically defines **sta1** as a server and **sta2** as a client. Later on we will see examples of the most common way of using _iperf_. 1118 | 1119 | **Publications that have already used Mininet-WiFi for performance research**: 1120 | 1121 | - Gilani S.M.M., Heang H.M., Hong T., Zhao G., Xu C. _OpenFlow-Based Load Balancing in WLAN: Throughput Analysis_. Communications, Signal Processing, and Systems (CSPS), 2016. 1122 | - Krishna Vijay Singh, Sakshi Gupta, Saurabh Verma, Mayank Pandey. _Improving performance of TCP for wireless network using SDN_. Proceedings of ICDCN, 2019. 1123 | 1124 | 1125 | 1126 | ## Mobility models 1127 | 1128 | Mobility models are also very important because they try to mimic the mobility of persons, vehicles or any other object that is mobile, i.e. able to move from one point to another. There are several studies that try to identify the patterns of human mobility during natural disasters, such as major storms, floods, etc. 1129 | 1130 | 1131 | As for the propagation models, there are several mobility models that are accepted by the scientific community worldwide, and some of them are supported by Mininet-WiFi, such as _Random Direction_, _Random Walk_, _Gauss Markov_, among other models. Mobility can be observed either using CLI or a graph, as illustrated in the figure below. 1132 | 1133 | ![Working with mobility](figures/graph-mobility.png "Working with mobility") 1134 | 1135 | Because of their importance, we will now check how mobility models can be configured on Mininet-WiFi. To do so, let us use the <_mobilityModel.py_> script, which contains the _Random Direction_ mobility model in its code. It is important to note that for each mobility model there may be unique parameters such as minimum and maximum speed limits, areas where nodes can move, etc. All the information you need about mobility model settings can be found on Mininet-WiFi's [web page](http://mininet-wifi.github.io/). 1136 | 1137 | 1138 | _Seed_ is one of the most important mobility model settings. It modifies mobility significantly. For instance, if a _seed_ number one causes the nodes to move from certain x and y values, a seed number two will change the initial values of x and y. It will not be able to change the mobility behavior, but it may change its own initial positions. This is an important feature because the initial arrangement of the nodes may not always meet the requirements defined for a particular experiment. 1139 | 1140 | 1141 | Now that we know a little more about the theory of mobility models, let us run the following script and observe how the nodes behave when configured with the _Random Direction_ mobility model. 1142 | 1143 | ``` 1144 | ~/mininet-wifi$ sudo python examples/mobilityModel.py 1145 | ``` 1146 | 1147 | 1148 | info Record the behavior of the nodes and try to change the mobility model at a later time for comparison purposes. 1149 | 1150 | 1151 | Then we will test two of the three implemented Mininet-WiFi commands that were presented in https://github.com/ramonfontes/mn-wifi-ebook/blob/main/beginner.md#first-steps-to-use-mininet-wifi: `stop` and `start`. 1152 | 1153 | 1154 | Let us first try the `stop` command. 1155 | 1156 | ``` 1157 | mininet-wifi> stop 1158 | ``` 1159 | 1160 | Should everything go as expected, the `stop` command will cease mobility, causing the nodes to stop moving. This feature is useful in cases where the user wishes to observe information such as signal strength or even available bandwidth connected to an arrangement of nodes. 1161 | 1162 | 1163 | Now, we can issue the `start` command to resume mobility. 1164 | 1165 | ``` 1166 | mininet-wifi> start 1167 | ``` 1168 | 1169 | warning All mobility models supported by Mininet-WiFi can be found in <_mn\_wifi/mobility.py_>. Should you want to implement new mobility models, you must include them in this file. 1170 | 1171 | 1172 | **Researches that used Mininet-WiFi for experimentation on mobility**: 1173 | 1174 | - K. V. K. Singh, M. Pandey. _Software-defined mobility in IP based Wi-Fi networks: Design proposal and future directions_. IEEE International Conference on Advanced Networks and Telecommunications Systems (ANTS), 2016 1175 | - N. Kiran, Y. Changchuan, Z. Akram. _AP load balance based handover in software defined WiFi systems_. IEEE International Conference on Network Infrastructure and Digital Content (IC-NIDC), 2016. 1176 | - D. Tu, Z. Zhao and H. Zhang. _ISD-WiFi: An intelligent SDN based solution for enterprise WLANs_. International Conference on Wireless Communications \& Signal Processing (WCSP), 2016, 1177 | - H. T. Larasati, F. H. Ilma, B. Nuhamara, A. Mustafa, R. Hakimi and E. Mulyana, _Performance evaluation of handover association mechanisms in SDN-based wireless network_. International Conference on Wireless and Telematics (ICWT), 2017. 1178 | - C. H. F. dos Santos, M. P. S. de Lima, F. S. Dantas Silva, A. Neto. _Performance Evaluation of Multiple Attribute Mobility Decision Models: A QoE-efficiency Perspective_. International Conference on Wireless and Mobile Computing, Networking and Communications (WiMob), 2017. 1179 | - Y. Bi, G. Han, C. Lin, Q. Deng, L. Guo and F. Li. _Mobility Support for Fog Computing: An SDN Approach_ IEEE Communications Magazine, 2018. 1180 | - A. Kaul, L. Xue, K. Obraczka, M. Santos, T. Turletti. WiMobtit{Handover and Load Balancing for Distributed Network Control: Applications in ITS Message Dissemination_. International Conference on Computer Communication and Networks (ICCCN), 2018. 1181 | - Z. Han, T. Lei, Z. Lu, X. Wen, W. Zheng, L. Guo. _Artificial Intelligence Based Handoff Management for Dense WLANs: A Deep Reinforcement Learning Approach_. IEEE Access, 2019. --------------------------------------------------------------------------------