IoT Networking Using MPTCP Protocol

(1)

M

ÄLARDALEN

U

NIVERSITY

S

CHOOL OF

I

NNOVATION

,

D

ESIGN AND

E

NGINEERING

V

ÄSTERÅS

,

S

WEDEN

Examensarbete för kandidatexamen i datavetenskap, 15,0 hp

I

O

T

N

ETWORKING USING

MPTCP

P

ROTOCOL

Hawkar Karim

Ham17002@student.mdh.se

Examiner: Hossein Fotouhi

Mälardalen University, Västerås, Sweden

Supervisor: Iliar Rabet

Mälardalen University, Västerås, Sweden

(2)

1

Hawkar Ahmed Karim IoT Networking Using MPTCP Protocal

Abstract

The progress of technology is moving in a rapid pace forward, with new solutions and improvements being developed each year. Internet of Things (IoT) is one area of computer science that seen a growing interest from the population leading to more deployments of the technology. IoT devices often operate in low-power lossy networks making them depend upon low energy consumption but also high reliability. As the devices become more mobile this also exposes several challenges, one being connectivity in regard to mobility. Our proposed solution to this problem use Multipath Transmission Control Protocol (MPTCP) as a way of delivering high level of performance and connectivity and thereby high reliability. There has been research and implementations of MPTCP in different networks, however in low power radio networks, such as the ones IoT devices resides in, it is still a novel idea. We reproduced and tested an implementation of MPTCP, against a similar network that is using regular TCP and compared the results. The MPTCP network showed a higher throughput and data transfer, proving to be more efficient while also providing a higher level of reliability in regard to connectivity. However, MPTCP showed a higher rate of packet retransmission compared to regular TCP. To be able to fully deploy MPTCP in low energy IoT devices there needs to be more improvements to accommodate the needs that such networks depend upon. There are use cases, such as for mobile cellular devices where MPTCP would make an impactful difference.

(3)

2

1. Introduction ... 4

2. Background ... 5

2.1.

Internet of Things ... 5

2.2.

Wireless Sensor Networks (WSN) ... 5

2.3.

Transmission Control Protocol (TCP) ... 6

2.4.

Multipath Transmission Control Protocol (MPTCP) ... 6

2.5.

IEEE 802.11 protocol ... 7

2.6.

Mininet and Mininet-WiFi ... 8

3. Related Work ... 9

3.1.

Towards WiFi Mobility without Fast Handover ... 9

3.2.

How Far Can We Go? ... 9

3.3.

Energy Constrained Multipath Routing in Wireless Sensor Networks ... 10

3.4.

TCP and MPTCP Retransmission Timeout Control for Networks Supporting WLANs 10

3.5.

QoS Evaluation of MPTCP over a Multi-Hop Wireless Network for IoT Devices . 11

4. Problem Formulation ... 12

5. Method ... 13

5.1.

Experiment and literature study as method ... 13

5.1.1. Research ... 13 5.1.2. Experiment in simulation environment ... 13 5.2.

Development Environment ... 13

5.3.

Implementation ... 13

5.4.

Network testing ... 15

5.4.1. Iperf ... 15 5.4.2. Test details ... 15

6. Ethical and Societal Considerations ... 16

7. Implementation and testing ... 17

7.1.

Prerequisites ... 17

7.2.

Mobility ... 17

7.3.

Testing metrics ... 17

7.3.1. Throughput ... 17 7.3.2. Packet Retransmitted ... 18 7.3.3. Roundtrip time ... 18 7.4.

Testing on the network ... 18

(4)

3

8. Results and discussion ... 19

9. Conclusions ... 24

10. Future Work ... 25

11. References ... 26

A. Mptcp.py Code ... 28

(5)

4

1. Introduction

The progress of technology is moving in a rapid pace forward, with new solutions and improvements being developed each year. Corporations and various institutions have come to benefit from this progress which has amongst other things led to higher efficiency and/or automation. Internet of Things (IoT) is one area of computer science that have seen a growing interest from the population leading to more deployments of the technology. To keep developing in this area is an important task so we can accommodate the growing need for data performance in today’s world. Some media such as streaming movies or playing high demanding games on a mobile device, is getting bigger in size and higher in quality. This makes the need for research and development an essential part for moving forward and dealing with this demand. There are several theories and ways to go about in trying to evolve the area, this thesis however will focus on developing on the limitations, in particular the ones regarding mobility. Improving on the mobility factor would not only be beneficial for IoT but also for other technologies using for example WiFi as its communication method.

IoT can be defined as a collection of different devices that are connected and either communicating and sending data between each other or over the Internet [1]. For the regular consumer these types of products can manifest themselves as smart-TVs, smart thermostats, or security systems, these devices and networks have several advantages but also limitations. When addressing the problem of mobility, Kabilan K. et al. points out for example how important it is to accommodate the need for efficient routing protocols since our devices are becoming more mobile and requiring data transfer on the go [2]. The goal is to reach high Quality of Service (QoS) regarding different attributes such as reliability and efficiency. When it comes to connectivity of the mobile device, it usually is connected to what is called an access point (AP) [3]. When the device moves and starts losing connectivity to that access point, it initiates what is called a handoff. What this handoff does, is that it finds another AP to connect to and during this swap there is some amount of downtime. The strategy of a quick handoff and trying to lower that latency has been a focus for a lot of research in order to get a higher QoS. Issues still coupled with this strategy is that it can in some cases still pose a long handover latency, a high energy consumption related to nodes needing a higher signal strength as they move further from the receiving node and also a higher rate of packet loss due to the increasing distance [4].

In this report, the focus will be on the possible solution for some of the problems regarding mobility using Multipath Transmission Control Protocol (MPTCP). Regular Transmission Control Protocol (TCP) works by a three-way-handshake being performed between a sender and a receiver, like the node connecting to an AP. When a handover is initialized, a teardown of this connection is made, and a new three-way-handshake is established with the new connection. In MPTCP however, this type of connections is made to all the available AP’s in the network and therefore minimizing the latency time, if routing is made correctly.

Research has been done regarding minimizing the handoff time and the use of MPTCP as an optimized version for regular TCP connections in applications that is using TCP today. However, the use of MPTCP as a substitute of regular handoff in IoT networks is still a novel idea and therefore an interesting topic regarding if MPTCP can increase network reliability and timeliness in mobile IoT networks. This thesis implements the MPTCP protocol using the IEEE 802.11 which is a WiFi radio. Testing and comparison of the performance and other metrics has been done and analyzed against regular TCP to showcase any advantages or disadvantages.

The simulation software used is called Mininet-WiFi which is a network simulator that is designed to create and simulate real life networks and with features enables us to perform network testing. There are two codes used in these tests and the first is an open sourced code which is implementing MPTCP network and the second a self-written code in Mininet-WiFi implementing regular TCP network. On these two networks, tests have been conducted using the iperf tool which generates TCP data stream. Since MPTCP is an extension of TCP, it still uses regular TCP data for transfer and therefore enables us to compare the results.

(6)

5

2. Background

2.1. Internet of Things

Internet of Things (IoT) is an umbrella term for a new area in Internet and technology. The term dates back almost two decades when it was possible first mentioned and since then those words has come to play a larger role in our lives [1]. There are many different definitions to what IoT actually is and what is necessary for something to qualify for that category. However, there is one key element that almost all the definitions seem to have in common; the Internet. To be categorized as an IoT device you simply need to be any ordinary everyday object that has connectivity to the Internet and are therefore able to send and receive data between them or to a remote controlling computer.

Some of the more known IoT devices for regular customers and individuals are the ones called “Smart home devices”. These objects and devices have a wide selection ranging from smart refrigerators, watches and lightbulbs. Dutta and Mahuya define four core foundational pillars of IoT as the “4Cs”;

1. “Connect: Interconnected devices and information.

2. Compile: Vast amounts of data collection in near real-time from a wide range of smart devices connected to the Internet.

3. Compute: Transformation of collected data through advanced techniques to uncover valuable insights.

4. Craft: Creation of new possibilities through interconnected devices and information leading to newer business models, and innovative solutions.” [5]

2.2. Wireless Sensor Networks (WSN)

Being connected and accessible through Internet relaying real-time data opens up for many areas of applications for the technology. Ranging from the regular individual customer to military use. IoT sensing devices can be used to monitor an area for chemical substances in the air and relay this information to soldiers on the ground or a head quarter [6].

Sensing nodes are deployed in the area that needs the monitoring. Depending on the range capabilities of the nodes or the constraint that is put on them, these nodes create what is called an “coverage area”. The nodes themselves usually have four different states, sensing, relaying, sleeping and dead. These nodes communicate and relay the data between them forwarding it to the sink, which can be seen as the end node. This node finally uses the Internet to relay the data to the monitoring computer. This kind of system has many limitations in the form of the hardware itself to environmental factors. The nodes are regarded as a cheap computer that has limitations regarding range, power and computational capacity so they are prone to failure.

(7)

6

2.3. Transmission Control Protocol (TCP)

TCP is the most popular transport layer protocol that is being used on the Internet and has also become the standard for Internet-based commercial communication networks [7]. One of its features is the sending of an ACK for acknowledgements or SYN for synchronize used for requests. A TCP connection is established by performing what is called a three-way-handshake between the sender/client and receiver/server. In the handshake the sender and receiver share information about each other, sequence numbers and other information needed for the connection to be working in the form of sending packets. In the first step the client will send a SYN packet, a request to start establishing the connection and it will send along a starting sequence number. The server will then respond with a SYN-ACK packet, which is saying that it has acknowledge the clients request and sending along the servers starting sequence number. And finally, the client will respond by sending an ACK packet to the server, acknowledging that it has received the information and that they are now ready to start communication through this connection. Now a single connection has been made between the client and the server, if the client wants to connect to another server, it has to do the same steps again for that new server. Packets can be lost or damaged during transport if this happens, then an ACK will never be sent back to confirm that we received the packet. After a while of waiting for the ACK that does not arrive, the sender will simply resend that packet again, and wait for an ACK for the newly sent packet, this leads to TCP connection being highly reliable.

The rate of which the sender sends packets can lead to problems, if the sender tries to send more packets then the network can handle, it can get congested. Congestion leads to lowered Quality of Service (QoS) and can manifest itself in excessive packet delay, high frequency of packet loss and high number of retransmissions. TCP has a built-in congestion control that contain the max amount of data that can be sent out without having received an ACK from. When a new connection is established and we start sending data we enter what is called a slow start, which for each successfully sent packet, increases the possible sending rate. However, when the amount of packet loss becomes high enough, it assumes that there has been a congestion somewhere and therefore the sending rate will we decreased by half.

2.4. Multipath Transmission Control Protocol (MPTCP)

Multipath Transmission Control Protocol (MPTCP) is an extension of the regular TCP. The problems that MPTCP is set out to fix is the ones regarding connectivity between a node and an end receiver, especially in regard to mobility [8]. A smartphone for example can have one active connection which it is sending data through, either 3G/4G or Wi-Fi. These two connections, however, recognize the smartphone by two different IP addresses which poses a problem when the smartphone node is moving from one connection to the other. When the node is connected via Wi-Fi and moves away from it, the signal gets weak until eventually dropped and switched to the 3G/4G network. This then leads to the TCP connection made between the smartphone and Wi-Fi has to be torn down and a new TCP connection must be established with the new network. This leads to poor QoS in the form of possible high latency and downtime until the switch is completed.

Paasch and Bonaventure explains the design goals of MPTCP as the following: 5. “It should be capable of using multiple network paths for a single connection,

6. It must be able to use the available network paths at least as well as regular TCP, but without starving TCP,

7. It must be as usable as regular TCP for existing applications, and

8. Enabling MPTCP must not prevent connectivity on a path where regular TCP works.” [8] A MPTCP connection is established in the same way as regular TCP via a three-way-handshake, the only difference is that the client and server tell each other that they are MPTCP capable and if they both are, such a connection is established. Now instead of having one path/flow where data is transmitted there can be multiple subflows. The congestion control works differently on MPTCP whereas is has the option to send data on different routes as shown in figure 2. If it detects that one of the subflows is getting

(8)

7

congested, has high rate of packet loss or gets a timeout, then MPTCP can start sending more new traffic or resend the lost packets through the subflow that is not congested.

Figure 2. MPTCP between sender and receiver with two subflows.

For the previous case with the smartphone Paasch and Bonaventure explains three possible solutions using the MPTCP since it enables different kinds of handovers to provide a seamless experience for the user [8].

9. The first is make-before-break. When the user moves away from the Wi-Fi, the radio signal gets weaker. MPTCP can now predict that the connection will probably go down, so it can start a new subflow over 3G/4G and start transmitting data on that flow.

10. The second is break-before-make. When one of the flows experience a failure, MPTCP can create a new flow and start resending the lost data over the new flow.

11. The third alternative is to simply have flows over both the Wi-Fi and 3G/4G working simultaneously. There are pros and cons to this solution, such as wasted energy, but Paasch and Bonaventure points out that the cost of the energy being sent over two different interfaces can be earned back in the form of for example less display time since the data will be sent much quicker and with a lower failure rate.

2.5. IEEE 802.11 protocol

The Mininet-WiFi networks use the IEEE 802.11 protocol which is a protocol widely used in Wireless local area networks (WLAN) [9]. WLAN’s make use of what is called carrier sense multiple access

with collision avoidance (CSMA/CA). What it does is when a node has a packet that is ready to be

transmitted on the channel, it listens to the channel. When the channel is free for transmission, meaning that the energy level on the channel is lower than the clear channel assessment threshold. When this is done then the node starts a counter given a random value and counts backwards. If traffic is being detected on the channel then the counter pauses, and when reaching zero the packet is

transmitted. There is also a second type of the CSMA and that is the carrier sense multiple access with

collision detection (CSMA/CD). Compared to CA that handles collision by trying to detect them

before it has transmitted, CD detects collisions after the data has transmitted. When a collision has been detected CSMA/CD will jam the transmission, hold for an amount of time, and then retransmit the data that was involved in the collision.

The protocol has been around for decades and as for most of technology it has evolved with the times and conforms to the newer criteria’s set upon it. For example, together with the evolution of IoT devices comes the need for more power saving and efficient protocols. The IEEE 802.11af-2016 and IEEE 802.11ah-2016 conforms to such needs by further expand the application scenarios of WLAN’s to provide features enabling cognitive-radio, long-range communication, advanced power saving

(9)

8

mechanisms and support for machine-to-machine devices. Fitting to this thesis, [9] points out the upcoming future needs and challenges which WLAN’s face;

• Addressing dense scenarios caused by the continuous deployment of access points, and the provide higher transmission rates.

• Also, the significantly increased need for throughput brought on by the higher usage and demand of real-time high-definition audio/video content.

Such development is being done, [9] mentions the High Efficiency WLAN (HEW) Task Group currently developing a new high- throughput amendment named IEEE 802.11ax-2019.

2.6. Mininet and Mininet-WiFi

Mininet is a network simulator that is capable of creating networks and topologies that mimics real-life

behaviors [10]. The topologies can be built and consist of nodes, access points, switches and hosts. It allows for developing and testing networks that can be moved into compatible real system without any larger changes being made to the network and code. This is possible since the application runs real code, including standard Unix/Linux network applications and also uses the real Linux kernel.

Mininet-WiFi is an extension of the Mininet emulator that allows wireless channel emulation, node

mobility and support of the 802.11 protocol [11]. Mininet-WiFi offers several utilities which makes the ability for developing and testing the network for real-life scenarios. One of these utilities is the enabling of emulation of Traffic Control which opens up for the features brought by Linux kernel packet schedular such as; control packet rate, delay, latency and loss.

Mininet-WiFi also supports the act of mobility on the nodes and supports different mobility models such

as Random-walk, Walk, Random Direction et cetera [11]. The models mostly work by moving the node one step, pausing and through mathematical equations calculate a next step which all have the same probability. This combined with the former mentioned aspects of Mininet-WiFi makes it a useful testbed for real-life use cases.

(10)

9

3. Related Work

The research regarding MPTCP or other ways to get higher efficiency in networks is still a novel idea. MPTCP implementation into real world systems have not gotten to the point of being a widely adopted solution, and therefore research regarding the topic is of interest especially in regard to mobility. In this section we will present related work and put them into relation to our work.

3.1. Towards WiFi Mobility without Fast Handover

An MPTCP approach to solving the problems that occur within handover scenarios in a mobile environment is presented by Authored by A. Croitoru, D. Niculescu and C. Raiciu. They formulate their methodology with the motivation that research regarding solutions of bringing the handover downtime to a minimum is not the optimal solution [3]. Experiments and tests are being done on a scenario where a cellular mobile device is connected to a WiFi network and move away from that access point (AP). When such a scenario occurs, the signal gets weaker until eventually dropped. From this point, what is called a handover scenario is initiated resulting in a teardown of the WiFi connection and an establishment of the cellular connection. Their opinion on this being the wrong approach is based on many reasons including: (I) To start a handover the connection need to be lost, which results in bad user experience, (II) If there are several AP’s to connect to, there is no standard way of deciding which AP will lead to better performance in longer durations, and (III) When a AP has been chosen there is no way to dynamically change adjust to changes in signal strength or load. A. Croitoru et. al. presents their solution where the device instead of scanning and connecting to a single AP, connects to all accessible AP’s in range and operate through MPTCP. This will allow for a clean, technology independent end-to-end solution for mobility brought on by the better performance in metrics such as throughput and connectivity.

The implementation is conducted in the 3.5.0. Linux kernel using MPTCP v.0.89 with different IEEE 802.11. standards for WiFi depending on the experiment and tests. Several experiments are conducted however, one being more relevant for this thesis; a real-life experiment testing with the mobility factor. The user starts in a building with mixed WiFi coverage established by five different AP’s. From the second floor in a lab the user then walks down a flight of stairs to the first floor and into a cafeteria. The test is conducted a series of times with different use cases and testing scenarios. The results of the tests that holds the most value for this thesis, all show better throughput performance, and the authors conclude that MPTCP is a viable solution for higher performance and user quality experience, especially when factoring in the element of mobility.

This is one of the primary works that this thesis tries to validate and extend the affirmation on the results that have been produced. In our thesis we also use the Linux kernel, MPTCP and the IEEE 802.11 protocol. The main difference compared to the work of A. Croitoru et. al. is that our thesis focus on purely simulation testing and the results on a higher-level scale of context, whilst A. Croitoru et. al. focuses in on more detailed properties. The amount of use cases and scenarios for testing are also far more than those presented in this thesis thereby delivering a more comprehensive result. However, the results from the tests lining up with the ones in this thesis can be compared and could showcase either a difference in results or validate them.

3.2. How Far Can We Go?

“How Far Can We Go? Towards Realistic Software-Defined Wireless Networking Experiments” is a work authored by Fontes R., Mahfoudi M., Dabbous, W., Turletti, T., Rothenberg, C [11]. In this work Fontes et. al. discusses the impact that WiFi has had on our devices and our daily lives. The ability to test and develop to further move the technology forward with new solutions and improvements is not always easy. The authors bring up difficulties regarding the move from simulations and testing to actual roll-out with functioning properties. Such challenges manifest themselves for example in hardware availability, protocol implementations in software, resource constraints, realistic evaluation models and development and testing costs and efforts. To combat these challenges the authors, propose the use of

(11)

10

the simulator Mininet-WiFi which possesses capabilities for a much simpler path from test and simulations of a network to actual deployment. One test that they perform is to evaluate the possible performance gain when using MPTCP in conjunction with Software Defined Network (SDN) path control. MPTCP is designed to be an end-to-end protocol which means that it does not control which path the data takes over the sub flows from the source to the destination. SDN helps solve this problem since its OpenFlow controller has an overview of the network and can contribute in the decision-making of which path is more stable or beneficial to send the data over. This will help with performance when it comes to detecting problems such as congestion or broken connections. By testing a network created in the Mininet-WiFi simulator against a similar real-life psychical network, the result showed that the performance and metrics vary by very little and thus Mininet-WiFi poses as a viable alternative as a testbed. This is a result of the simulator using core features that may be found being used in real-life network deployments.

This thesis’ implementation has reproduced the experiment that Fontes R. et. al. has conducted regarding MPTCP, using the same mptcp.py code that is used in their work. The goal of our work is to extend upon the results and goals of Fontes R. et. al. work by adding the element of mobility into the tests. Further we also compare the result from the use of MPTCP against regular TCP instead of comparing the MPTCP results against a real-life network.

3.3. Energy Constrained Multipath Routing in Wireless Sensor Networks

A work by Bagula A. B. and Mazandu K. G. where they formulate a model called Energy Constrained Multipath Routing (ECMP) that complies to a quality of service way of routing in wireless sensor networks. The goal of ECMP is to be an alternative way of routing that results in showcasing more energy efficiency compared to similar solutions [6]. Essentially the proposed model takes in account the expected energy consumption when choosing a path. The results showed that the ECMP model does result in a more energy efficient and also less hops.

This thesis is based on the MPTCP which differs from the work of Bagula and Mazandu who are focusing on the routing aspect. However, the results and tests show the potential a multipath solution can have on a different set of use cases. Factors such as energy consumption is of high of interest and should be monitored for future work when it comes to the MPTCP.

3.4. TCP and MPTCP Retransmission Timeout Control for Networks

Supporting WLANs

In this work by Shin S., Han D., Cho H., Chung J., Hwang I., Ok D., they bring up problems regarding the current retransmission timeout (RTO) algorithm [12]. This algorithm is used in transport layer protocols such as TCP and MPTCP however, the authors argue that the current model of the algorithm is designed for wired networks. Since it is also used in IEEE 802.11 wireless local area networks (WLAN), this will showcase different problems since it is not optimized and properly prepared for this wireless application. The authors propose a solution to this problem by performing experiments on a new algorithm called WLAN RTO (WRTO) that can be applied on to TCP and MPTCP.

What the RTO algorithm does is that it detects data delivery failures in end-to-end paths, this can be due to loss or damaged packets, and is based on the lack of receiving an ACK of the sent packet. Even though being a solid solution for reliability, problems occur when moving this to the wireless connections, since in wireless connections packet loss is much more common and probable. This can be because of interference or mobility of the devices. So what the authors propose is their algorithm WRTO that takes these problems, such as packet error and delay characteristics of WLAN in consideration. Together with this they also propose a WLAN MPTCP (WMPTCP) scheme that uses the mentioned WRTO algorithm to improve performance when it comes to concurrent transmission or flow switching based multipath networking. What the WRTO algorithm is set out to achieve is a faster recovery while avoiding spurious timeouts.

(12)

11

Their proposed WMPTCP scheme supports both concurrent transmission which the current MPTCP scheduler does, but also path switching. This allows WMPTCP to check for path conditions and different characteristics do decide which flow it should send its data through. This will help the performance of MPTCP when it comes to congestion and other path problems that can occur.

The authors performed experimental testing and simulations and compare them to current algorithms and schemes. What they could conclude was that their proposed solutions outperformed the other schemes. For example, 18%, 29% and 68% faster recovery compared to PF, cWPTCP and CMT-QA.

The point that the authors bring to light regarding the technology not being fully adapted to the current situation when it comes to wireless environments is an important point to keep in mind during the conducting of this thesis. This highlights the further work that can be done on the technology and applications to provide even better performance and reliability. Since this thesis will perform its simulations and test in the 802.11 wireless environment this is important to keep in mind.

3.5. QoS Evaluation of MPTCP over a Multi-Hop Wireless Network for IoT

Devices

Izumi K., Yoshihiro I., Kensuke N has in their work evaluated the Quality of Service (QoS) of MPTCP when used in a multi-hop wireless networks that is used for IoT devices [13]. The authors mention the increase of smart home appliances and overall IoT devices that often uses the Internet over a wireless local area network (LAN). They bring up problems connected to this area such as the coverage of the wireless LAN could be restricted or that the communication can become unstable.

What the authors propose to solve the mentioned problems, they propose the use of wireless multi-hop communications. In this type of environment, the devices relay data between their neighboring devices. In this way the coverage area can be much greater than one single device can accomplish.

Two different experimental environments have been used to conduct the experiment in the work. In one of the environments the radio intensity between the devices varies. In in the other environment both the number of devices and the radio intensity between the devices varies. The network consists of three types of devices; a sender, a receiver and routers.

What they concluded from the tests was that the degradation of the signal strength the throughput. To try to combat this issue, the authors inserted a router between routers in an attempt to strengthen the signal intensity. However, this did not lead to any higher performance in the throughput. This was connected to the delay that the routers themselves cause when in a network.

This work is very much related to the work conducted for this thesis and also provides with interesting and important results. The result regarding the added router not leading to improved performance was very useful. And also leads to questions regarding different improvements that can be made to try and combat this problem of not providing any higher throughput.

(13)

12

4. Problem Formulation

IoT is a technology that has many challenges and improvements that can be solved so that IoT devices would work better and more efficiently, one of these problems is the problem of mobility in regard to connectivity. When a device is connected, it usually is connected to something called an access point (AP). When the device moves and starts losing connectivity to that access point, it initiates something called a handoff. What this handoff does, is that it finds another AP to connect to, and during this swap there is some form of downtime.

In recent times, much of the focus has been put into decreasing this downtime, making the switch between AP, fast and seamless to avoid the user noticing it. However, what we will try to accomplish during this thesis is the possibility of using what is called Multi Path TCP (MPTCP), which is where the device instead of connecting to only one AP, connects to all nearby AP and splits the data-transfer between them. There has been research and implementation of MPTCP in different networks, however in low power radio networks, such as IoT devices resides in, it is still a novel idea. Using MPTCP could improve mobility and cut of any downtime that the device could previously be exposed to. We will try and accomplish this on the IEEE 802.11 radio which is used in low-power wireless networks.

The goal of the thesis is to see if it is possible to implement working MPTCP over the IEEE 802.11 radio and if so, can it be proven to be a solid solution for the mobility issue instead of using for example handover? Answering these questions will open up for opportunities of further research in the area and could lead to enhance user experience in regard to QoS, increasing efficient data transfer in IoT devices and also increase the lifetime of nodes in regard to lower energy consumption.

(14)

13

5. Method

5.1. Experiment and literature study as method

5.1.1. Research

The initial focus was on performing the literature study by collecting data and information regarding the technologies and areas. Therefore, in the beginning it was essential to focus on searching and reading scientific articles and reports containing key words such as IoT, TCP, MPTCP, mobility and low-power radio. The search for these reports and articles was done on search engines such as Google Scholar and

Mälardalens Högskola database, filtered to only show peer-reviewed results. Knowledge of these areas

are required for being able to understand the necessary parts for the final working code and design but also what the appropriate tests should be. This part also consisted of researching different development environments that could best accommodate the needs and requirements set to fully being able to perform and evaluate the created networks.

5.1.2. Experiment in simulation environment

Performing experiments in a simulated environment was chosen as the appropriate method to find the answers to the thesis problem formulation. This has been done by reproducing the MPTCP experiment done in [11] by implementing the provided code in [14]. The goal of the experiments is to produce results that is viable and can be compared, and to be able to do this the variables of the test must be kept as similar as possible. In the paper [15] they point out the importance of being able to reproduce experiments for making a scientifically claim. They also continue with stating how results can scientifically vary depending on a number of factors such as difference in hardware and software and this is something we have taken in account for in this thesis. However, since we in this thesis are not directly comparing our results to the results in [11], we avoid this problem. Our tests are only based on the [14] code implementation and compared to a self-written code. Both are executed and analyzed from the same testbed including the same hardware and software. Some fundamental ideas from [15] has been taken in consideration when performing the tests, such as how many “runs” is needed and for how long each run should last. The tests are performed with two tests over the course of three days and each test is executed for a period of 60 seconds. Since the results showed almost exactly the similar result, an average of the tests has been chosen and presented as the final result.

5.2. Development Environment

For development and testing the environment, Mininet-WiFi was chosen among other things for its capabilities of emulating realistic real-life networks, the support for mobility and the amount of available documentation. The networks will go through tests and be compared on different metrics, and one of them will be the impact on the result due to mobility. Mininet-WiFi supports the static position placement on the network and also support different mobility models, in this case Random Walk. The model performs random movement of the selected nodes within a set x and y area. The two approaches will give us the opportunity to perform tests that will show us how the network behaves when using predicted distance (placing a node with static x and y position away from the access point), and the unpredicted distance (moving the node within a larger area containing the access point).

5.3. Implementation

Since the time for the thesis was limited, the time for the design and implementation of the code were also limited. The goal was to find an open source code that was implementing MPTCP so it could be used as a basis for further development to be used for the thesis’ purpose. Such code was provided by R. Fontes [14] that also fulfilled the requirements of being written in python and also made to be used in the Mininet-WiFi environment. The main reasons for choosing MPTCP/TCP as the protocols on the transport layer was because of it being widely adopted as the most popular protocol on transport layer and also for its reliability. When a packet for example is being sent from the client to the server, many things can happen, and packet loss is very common especially over wireless networks. TCP handles

(15)

14

these losses by resending them when an acknowledgement from the server has not been received. For most IoT networks this kind of feature would be desirable since they often rely on sending real-time data to the controller. However, there are applications where such feature is not considered quite as necessary. This can for example be video chat that more likely adopts the User Datagram Protocol (UDP) which does not handle loss at all. Since reliability is a key factor in TCP, monitoring the rate of packet loss and comparing the results of the two protocols used for this thesis, we can have a metric that could show us one protocol outperforming the other in different scenarios.

The topology of the MPTCP network is represented in figure 3 and consists of one station (STA1) acting as a client, two access points (AP2 and AP3) and one host (H10) acting as a server. The distance between STA1 and AP2 is statically set to be 8.06 meters, and the distance between STA1 and AP3 is 1.41 meters. These are connected with four switches (S6-S9) connected as illustrated and a POX controller which has an overview of the network topology.

Figure 3. Multipath TCP network topology.

To simulate regular TCP, a network with the topology shown in figure 4 was created. It consists of one station (STA1), one access point (AP1), one switch (S1) and one host (H1). The distance between STA1 and AP1 is 1,41 meters.

(16)

15

5.4. Network testing

5.4.1. Iperf

Iperf is a widely used tool that enables testing and measuring the networks performance and other elements. Key features which was desirable for this thesis’ testing include iperf’s ability to act as a client and server and send data streams between them. This can then be used to measure the networks and provide useful data outputs such as amount of data transferred and the throughput that was measured. Other metrics generated by iperf that is of interest is latency and packet retransmissions. Iperf also supports the usage of different parameters to customize the tool for a specific test, such as choice between TCP or UDP data stream and time. In our case, we will be using iperf’s TCP stream with default settings, regarding for example window size (64.0 Kbyte). Since MPTCP is an extension of regular TCP, using the TCP data stream of iperf will apply to both the protocols.

5.4.2. Test details

Two different test cases have been chosen to be used for the two different protocols. The first case is on a static network where the stations and access points are set to a fixed position with the distances in meters as mentioned in 5.2. In the second case we add the factor of mobility on the station-nodes, however the access points remain static. There are different mobility models to choose from that are built into Mininet-WiFi and for this test we have chosen the model Random walk. The reason for having these two test cases is to monitor the behavior and results of the network when they have as similar prerequisites as possible but also when some factors such as mobility, cannot be predicted.

The testing is conducted by performing three different tests when the networks are up and running: 1. Test the throughput of the network. We do this by running iperf -s on the server (H10) and

iperf -c 192.168.1.254 from the client (STA1).

2. Test roundtrip time (RTT) of packets using ping. We do this by issuing the command ping

192.168.1.254 from the client (STA1) and is conducted over a timespan of 60 seconds.

3. Test the throughput of the network while testing the RTT of packets using ping. We do this by issuing the command iperf -s on the server (H10), iperf -c 192.168.1.254 --time 60 –

interval 2 on the client (STA1) which sends data to the server over a timespan of 60

seconds. Simultaneously we also issue the command ping 192.168.1.254 from the client (STA1).

After the tests have been conducted the command netstat -s will be issued on both the server and the client which will display valuable information about the tests. What the tests aims to result in is which of the protocols show best overall throughput over the network (1), how long the RTT is for packets to be sent from the station to the host and back (2). Finally, how the RTT is affected when there is also traffic being sent back and forth on the connection (3). Comparing these metrics will show how the different protocols performance change and how they behave. Netstat can for example show the number of retransmitted/lost packets which is valuable information when evaluating the performance of the protocols. The metrics that will be analyzed and reviewed are (I) Throughput, (II) Packet RTT, (III) Packet RTT while data is sent on the connection, (IV) Packet retransmissions.

(17)

16

6. Ethical and Societal Considerations

The thesis adheres to all the regulations and requirements concerning the use of research, code and other material. Meticulous citing and referencing have been employed to highlight contribution of other writers and work that has been used for this thesis.

When it comes to the thesis’ topic and its goals it is difficult to find an element that would showcase itself as an ethical problem. The goal is simply to understand if an IoT network could benefit from using a multipath solution instead of a single path. The results of the thesis could be used as a basis for decision-making regarding such implementations which could lead to more efficiency and lower power consumption for example. However, there are still complications that could occur if poorly implemented or as a side effect of MPTCP in general. Such problems may be to saturate a link and therefore starving other connected nodes.

Problems could also occur when looking at it in a larger scale, for example what the IoT network is being used for during its deployment. There are several ethically and unethically justifiable reasons for deployment of systems, what they are being used for, how it could affect the environment et cetera. However, the conclusion is that this is out of the scoop for this thesis.

In general, the results from the thesis should bear positive outcomes and have a beneficial role in the ongoing development in the field. The work could lead to outcomes such as more efficient and economical usage and deployment. This could in the long-term help to bring down costs and open up for more areas of application where such networks would be beneficial.

(18)

17

7. Implementation and testing

7.1. Prerequisites

The underlying hardware used for the running and testing has been a MacBook Pro 13-inch 2017 model with a 2,3 GHz Dual-core Intel Core i5 processor and 8 GB of 2133 MHz LPDDR3 memory running the macOS Catalina operating system. The development, implementation and testing has been conducted on a VirtualBox running a 64-bit Ubuntu version 19.10 machine.

Following the steps provided in [16] installs Mininet-WiFi on the Ubuntu system. The regular TCP code and tests can run on Ubuntu’s default kernel 5.3.0-51-generic, however for running the MPTCP code and tests the MPTCP kernel [17] and Pox Controller [18] must be installed. Pox is an open source OpenFlow/Software Defined Networking (SDN) controller, and this controller is what is the main component in a SDN network. The controller is what is responsible for concentrating communications with all the elements in the network, providing a unified view of the network as shown earlier in figure 3 in section 5.3. The Pox controller enables for easily run OpenFlow/SDN experiments providing the ability to pass different parameters that for example makes real-life testing of topologies in Mininet possible. The Pox controller is activated through the following command and explained as followed: ./pox.py forwarding.l2_learning openflow.spanning_tree --hold-down log.level --DEBUG

samples.pretty_log openflow.discovery host_tracker info.packet_dum.

• L2 learning makes OpenFlow switches act like Ethernet learning switches. For example, in our case when different TCP connections are being established will result in different flows being installed. It has a built-in function that deletes flows if it is been idle for a set time of 10 seconds.

• Spanning tree is needed because our network contains loops. It builds a view of the network topology and constructs a spanning tree. If we have several alternative links and a link gets broken it can create a new tree that gets connected to that alternative link. In this way spanning tree reacts to network topology changes and handles them in such way that tries to ensure that we do not lose connectivity [19].

7.2. Mobility

To test how the networks react during the act of mobility on the station-nodes was a big part of the thesis’ goals. To perform mobility Mininet-WiFi has built-in models that emulates the scenario of the station-nodes moving around in the area. The mobility model takes in a set x and y coordinate which represents a boundary in the area which the node can move within but cannot pass. This area was set to a distance approximately 200 x 200 m in real life. The nodes can move in different ways depending on which type of mobility is chosen, and for this thesis the Random Walk was chosen with a max velocity of value 50 and minimum of 20.

7.3. Testing metrics

Different kinds of metric have been chosen for the testing that seems relevant to showcase the performance differences between the scenarios and protocols.

7.3.1. Throughput

Throughput can be stated as the average rate of which successful packets have been sent and delivered on the channel. This can for example be through Ethernet or in our case over radio. There are different metrics that could be applied to measure this, some common ones are bits per second or data packets per second.

(19)

18

7.3.2. Packet Retransmitted

Packet retransmitted is the calculation of the number of all lost or broken packets divided by the total number of sent packets over the channel. The number calculated should strive to be as low as possible, this means the channel has a low probability of packet loss and would therefore indicate a stable, reliable network connection. The following equation is used to calculate the number of lost packets per 100.000 sent packets:

𝑝𝑎𝑐𝑘𝑒𝑡𝑠_𝑙𝑜𝑠𝑡

𝑝𝑎𝑐𝑘𝑒𝑡𝑠_𝑠𝑒𝑛𝑡𝑥 100.000

7.3.3. Roundtrip time

Roundtrip time, or RTT, can have different definitions to it depending on the context, for our tests this is referred to as a measuring the ping. This means the time it takes for a packet to be sent from the source to the destination added with time for the acknowledgement for that packet to travel from the destination back to the source. A high or higher RTT than expected can be the result of many different reasons and factors. However, in our tests it will mostly be used to compare results for ping-time when there are no data traffic being sent on the connection versus the results for when there are data being sent on the connection.

7.4. Testing on the network

For the TCP tests, we begin by starting Mininet-WiFi and running the code called regularTCP.py. Once running the three different tests as seen in 5.4 are being conducted. Tests 2 and 3 are being conducted over a time period of 60 seconds. In between the tests the network is shut down and started to initialize a fresh start for each test. For the MPTCP the virtual machine is first booted with the MPTCP kernel running. Now the Pox controller is started, and its setup command as seen in 7.1 is executed and the code mptcp.py is executed.

For the mobility test, the code for mobility is added into the existing regularTCP.py and mptcp.py code, and the tests are again executed as above. Using netstat -s command and output in the terminals, relevant data and results are gathered. The packet retransmission was calculated on the results from test 3. The tests were conducted and subjected to the same conditions regarding the network. This include factors such as the condition of the network and signal strength. In all static tests without mobility, the station nodes have been placed well in signal range of the access point nodes. However, in the mobility tests, the stations have the possibility of moving out or range of the access points, leading to a weak signal and forms of path and propagation loss. This is one of the key elements in the test to observe how the connection and performance react to a weak or lost signal.

(20)

19

8. Results and discussion

The results based on the goals and target of the thesis have been gathered, analyzed and is represented in the following graphs.

Figure 5. Table with comparison of results of throughput between the different types of network when sending data between the

station and the host (client and server) using iperf commands.

The results from figure 5 is as expected, the throughput performance of the MPTCP network greatly exceeds the one of TCP. Having multiple paths to route the data leads to less chance for congestion and bottlenecks. The MPTCP kernel can measure the different routes to sense the load and congestion that they are currently carrying and route the packets to paths with lesser data traffic and congestion. This also leads to more data being able to be sent out on the network since the TCP window is getting filled and emptied in a much faster rate. The latency is also brought down on the MPTCP network for the same reasons as above, leading to more packets being sent quicker on the network. What would be interesting to observe is the actual time delay caused by the switches. What is expected is that some delay has to be taken into account since for example packet headers need to be changed to accommodate the new destination. Observing this time and its impact on the overall performance would be interesting since it could either point out that multiple switch routing leads to a disadvantage in overall performance or it being negligible in the larger context. Izumi K. et.al [13] performed an experiment on a multi-hop network using MPTCP in an IoT network to evaluate the throughput and performance of such networks. In their experiment they had a network consisting of a sender, receiver and two routers between them. In this network the signal was set to vary in strength which they concluded led to a decrease in throughput. In response to this behavior, they placed a third router in between the initial two in an attempt to see if the reinforced signal strength would lead to better throughput. What they discovered was that they could not increase the throughput of the multi-hop wireless network even if they added a router for increasing the signal strength. Some opposite behavior occurs for the TCP connection. Since there is only one path going from the station to the host, there is only one way for the packets to move. This leads to the TCP window to fill up and delays occur while waiting for the responses to clear the window, fewer packets are sent and the data transferred therefore become much lower compared to the MPTCP network. 9,71 394 6,81 56,4 0 50 100 150 200 250 300 350 400 450 Troughput

(21)

20

Figure 6. Using the ping command on the different network types to calculate the round-trip time of the packets being sent.

The results from the ping test in figure 6 shows some interesting result in regard to the max roundtrip time of the MPTCP protocol showing a very high value. This could be explained by a congestion taking place in that path however, since the overall average does not seem to be affected in a larger way, it seems like the MPTCP kernel was able to combat the issue. The overall higher values for MPTCP could be expected since it has two access points located with different distances from the station, one being at the same distance as the TCP’s access point, and the other with a longer distance. A longer path for the packet to be sent back and fourth from would result in a ping value being higher. The value could also be traced to the delay that occurs when moving through the switches, as pointed out earlier. Since the MPTCP network has four switches and the TCP only one, the impact on the roundtrip time is expected.

0,58 0,86 0,67 1,81 1,8 2,1 3,57 6,62 2,41 50,13 7,53 17,64 0 10 20 30 40 50 60

TCP MPTCP TCP with RandomWalk MPTCP with RandomWalk

Mi lli se co nd s Ping values

(22)

21

Figure 7. Initiating traffic on the different networks using iperf command while simultaneously executing ping command to

observe the round-trip time of packets while traffic is being generated on the connection.

The results from test number three in figure 7 show a significant higher performance for MPTCP both with and without mobility compared to TCP when testing the ping/RTT during traffic on the connection.

Figure 8. Table of comparison of average packets retransmitted per 100,000 packets sent on the different networks during the

tests conducted in figure 6.

Figure 8 showcases the results of retransmitted packets from the test performed in figure 7. The average rate of packet retransmission is significantly higher for the MPTCP compared to the TCP network both with and without mobility. This means that for MPTCP a higher performance when it comes to throughput and ping/RTT comes at the price of lower reliability with the higher rate of packet retransmissions. 0,7 0,65 3,01 2,72 2591,05 7,26 3706,77 98,34 3467,5 55,31 6137,88 185,94 0 1000 2000 3000 4000 5000 6000 7000

TCP MPTCP TCP with RandomWalk MPTCP with RandomWalk

Mi lli se co nd s

Ping values when traffic on connection

Min Avarage Max

1,65 22,65 5,37 154,72 0 20 40 60 80 100 120 140 160 180

Amount of packets retransmitted for every 100,000 packets sent

(23)

22

In the throughput test conducted in figure 5 with the mobility model, the result show MPTCP outperforming TCP however not to the extent as in the test conducted without the mobility. There is about an 86% drop in throughput performance between the test with mobility compared to without mobility. Observed is that the factor of mobility has a noticeable negative impact on the performance in throughput. Ping test with mobility in figure 6 shows similar expected results as in the results without mobility, with MPTCP performing better, however in this test the max is not as significantly noticeable. Analyzing the performance results conducted in these tests we can determine that MPTCP does have a greater advantage when it comes to higher throughput and connectivity. Connecting to several access points and using MPTCP have shown to greatly improve on the metrics that have been used for this thesis. Even though this experiment was not as comprehensive as the one conducted by A. Croitoru et. al. in their work [3], this further reinforces the results that they concluded. Firstly, in a static environment a multipath solution does offer better performance, including throughput and round-trip time, making it a useful methodology for future deployments. Secondly when it comes to mobility, we could also observe better performance and shorter round-trip times, further reinforcing the notion that MPTCP provide better performance with connectivity.

However, in regard to the goal of this thesis being the MPTCP use in IoT networks we still see the technology being problematic and not ready for full deployment as is. When conducting our test, we did find that even though the overall performance could be proven to be more successful, the rate of packet retransmission is still a problem. One key part of TCP is the reliability factor, even though in most cases impossible, the goal of the protocol is to provide zero amount of packet loss and retransmissions. Packet loss in a WiFi network is almost inevitable and is also a factor that needs to be taken in consideration when reading the results of packet retransmissions. Shin S. et. al. addresses this problem in their work [12] where they point out the same problem regarding packet loss and retransmissions on WiFi networks. They point out that the current retransmission timeout (RTO) algorithm is not designed for the new wireless technologies and protocols such as the 802.11 protocols. Since packet loss and retransmissions are inevitable in wireless networks, changes have to be made regarding how the protocols handles loss to accommodate this. What Shin S. et. al. proposed and evaluated was a new algorithm named WLAN RTO (WRTO) that can be applied to both TCP and MPTCP. In regard of MPTCP, they proposed a WLAN MPTCP (WMPTCP) scheme which the WRTO algorithm to improve performance. They could from the experiments conclude that the use of WRTO on WMPTCP outperformed the other schemes they tested against in terms of faster recovery and spurious retransmissions. This further the notice that MPTCP still has improvements to be made upon to be able to perform as a viable applicable solution, but with further research such problems could be solved.

Although this disadvantage, the MPTCP protocol still performed better in the regard of mobility which is also a key factor of IoT networks and a key element in this thesis’ goal. When taking this into consideration MPTCP could be a viable solution in regard to the test conducted by A. Croitoru et. al. [3]. Here the connection stayed connected during mobility since the device had connections established on all the access points available, instead of dropping the connection when moved out of reach from the signal. Furthermore as R. Khalili et. al. brings up in their work [20] MPTCP still have problems that need to be solved to be a completely viable solution. They bring up two problems (I) Upgrading some TCP to use MPTCP can reduce the throughput of others, without the upgraded users gaining any performance advantages. And (II) MPTCP users could be excessively aggressive towards TCP users. They attribute these problems to the linked increase algorithm used by MPTCP and the fact that more traffic then needed is sent on congested paths. They propose a solution that proves to solve these problems using what is called an opportunistic linked-increases algorithm. This furthers my argument of the need for research on the area, since even though the protocol may have problems and disadvantages researching and testing could lead to improvements to make MPTCP a fully useable protocol.

Another factor important to IoT networks is the notion of having as less energy consumption as possible since the devices usually have low energy capacity. Bagula A. B. et. al. presents in their work [6] the importance of working towards networks that consume less energy so that this can help in for example prolong the lifetime of the devices. In this paper we have not performed any measuring regarding the energy consumption of MPTCP against TCP. However, we can speculate that combining an energy

(24)

23

conserving routing algorithm such as Bagula A. B. et.al presented, together with the MPTCP protocol could be a solution to this. New tests must be made to observe if there is any tradeoff when using a MPTCP with efficient routing protocols against TCP with similar routing.

The overall financial cost of the MPTCP network implementation is something that needs to be taken in consideration. Using MPTCP could as we pointed out earlier lead to more energy consumption which leads to a lower lifespan of the devices. Devices that dies or breaks need to be replaced in the network. The costs surrounding such replacement are not only on the device, downtime and manpower for the actual change is also costs that need to be into consideration when deciding of which technology to use.

(25)

24

9. Conclusions

In this work we investigated and tested the MPTCP protocol to see if it could be a viable technology to be used in IoT networks where mobility is a factor. To solve this question could help future decisions regarding the use of the technology. If the MPTCP methodology could prove itself to be a viable solution more research would be done on the area and evolve it. Today there is a great need and demand for better performing devices when it comes to for example the daily user’s data consumption for games and streaming on portable devices. To fulfill this purpose and answer the thesis’ questions, experiments was performed comparing MPTCP against TCP. Their performance was observed during several tests and we collected the data on different chosen metrics. These experiments were split into two main categories,

with and without the use of a mobility model.

Our results show an overall higher performance and results on the metrics when using the MPTCP both with and without the mobility model. The throughput and data transfers of MPTCP were all higher in all of our experiments. The connectivity is much higher in MPTCP then in TCP since it connects to all nearby access points immediately instead of waiting for a connection to be lost to establish a new one. This increases the reliability factor of MPTCP especially when it comes to mobility and helps bring down the delay time. However, it also showed higher rate of packet retransmission, which is not a positive outcome, which needs to be taken into consideration whether the payoff is worth it. Therefore, in applications were there are unused bandwidth, but the delay is problematic, then the use of MPTCP would benefit in results of performance.

(26)

25

10. Future Work

For the future we think that our work could be extended in multiple ways since it is still a novel idea and an interesting solution to a current issue. Our experiments have a limited data span, more experiments could be done with several other metrics in regards. The use of more metrics would give a much deeper understanding and also a more detailed basis for decision making. Also experiments digging deeper in the actual packet transfer would generate interesting results.

Experiments regarding the energy consumption of MPTCP against TCP is of much need since one of the key factors of an IoT network is to have devices that is long-lived. These tests can be done on a routing level and see if a special energy conserving routing algorithm could be used to help keep a low energy consumption.

Testing and researching a coexistence of the technologies would also lead to interesting results. Today MPTCP works on top of TCP such as if both server and client are MPTCP capable such a connection should be established. An interesting topic could be to see if there are some testing that could be done before actually establishing the MPTCP connection to validate that the switch to that protocol use actually benefits the particular application.

Testing in a larger scale with more stations, switches, access points and hosts would generate more detailed results. The larger scale could also be more relevant to real-life deployments to show the performance advantages or disadvantages on a larger scale. It is possible that the results in this thesis are only applicable on smaller test sites.

(27)

26

11. References

[1] Berte D. R, “Defining the IoT”, Proceedings of the International Conference on Business

Excellence, vol 12, issue 1, Jun 2018.

[2] Kabilan K., Bhalaji N., Selvaraj C., Kumaar M. B., Karthikeyan P.T.R., “Performance analysis of IoT protocol under different mobility models”, Computers & Electrical Engineering, vol 72, pp. 154-168, Nov 2018.

[3] Croitoru A., Niculescu D., Raiciu C., ”Towards Wifi Mobility without Fast Handover”,

Proceedings of the 12th USENIX Symposium on Network System, Design and Implementation (NSDI ’15), May 2015.

[4] Ghaleb S. M., Subramaniam S., Zukarnain Z. A., “Mobility management for IoT: a survey”,

EURASIP Journal on Wireless Communications and Networking, 2016.

[5] Dutta N. S., Mahuya G., “IoT Driving Social Innovations”, Telecom Business Review, vol 11, issue 1, pp. 1-5, 2018.

[6] Bagula A. B., Mazandu K. G., “Energy Constrained Multipath Routing in Wireless Sensor Networks”, Ubuquitous Intelligence and Computing. UIC 2008 Lecture Notes in Computer Science, vol 5061, 2008.

[7] Leung K., Li O.k. V., Yang D., “An Overview of Packet Reordering in Transmission Control Protocol (TCP): Problems, Solutions, and Challenges”, IEEE Transactions on parallel and distributed

systems, vol 18, issue 4, pp. 522-535, Apr 2007.

[8] Paasch C., Bonaventure O., “Multipath TCP”, Communications of the ACM, vol. 57, issue 4, pp. 51-57, Apr 2014.

[9] Bellalta B.,”IEEE 802.11ax: High-efficiency WLANS”, IEEE Wireless Communications, vol.23, issue 1, pp. 38-46, Feb 2016.

[10] Mininet.org, ”Mininet Overview”, [Online]. Available: http://mininet.org/overview/. [11] Fontes R., Mahfoudi M., Dabbous, W., Turletti, T., Rothenberg, C., “How Far Can We Go? Towards Realistic Software-Defined Wireless Networking Experiments”, The Computer Journal, vol. 60, issue 10, pp. 1458-1471, Oct 2017.

[12] Shin S., Han D., Cho H., Chung J., Hwang I., Ok D., “TCP and MPTCP Retransmission Timeout Control for Networks Supporting WLAN’s”, IEEE Communications Letters, vol. 20, issue 5, pp. 994-997, May 2016.

[13] Izumi K., Yoshihiro I., Kensuke N., ”QoS Evaluation of MPTCP over a Multi-Hop Wireless Network for IoT Devices”, 2018 IEEE 7th_{Global Conference on Consumer Electronics (GCCE), pp.}

295-396, Oct 2018.

[14] Fontes R., GitHub Repository, [Online]. Available: https://github.com/ramonfontes.

[15] Anonymous, “TriScale: A Framework Supporting Reproducible Performance Evaluations in Networking (Version v2)”. Zenodo. 2020.

[16] INTRIG-UNICAMP, GitHub Repository, [Online]. Available: https://github.com/intrig-unicamp. [17] Paasch C., Barre S., et al., “Multipath TCP in the Linux Kernel”, [Online]. Available:

(28)

27

[18] Noxrepo, “Installing POX”, [Online]. Available:

https://noxrepo.github.io/pox-doc/html/#installing-pox.

[19] Linkletter, B., “Using POX components to create a software defined networking application”, [Online]. Available:

http://www.brianlinkletter.com/using-pox-components-to-create-a-software-defined-networking-application/.

[20] Khalili R., Gast N., Popovic M., Le Boudec J-Y., ”MPTCP Is Not Pareto-Optimal: Performance Issues and a Possible Solution”, IEEE/ACM Transactions On Networking, vol.21, issue 5, pp. 1651-1665, Oct 2013.

IoT Networking Using MPTCP Protocol

M

U

S

I

,

D

E

V

,

S

Examensarbete för kandidatexamen i datavetenskap, 15,0 hp

I

O

T

N

ETWORKING USING

MPTCP

P

ROTOCOL

Hawkar Karim

Ham17002@student.mdh.se

Examiner: Hossein Fotouhi

Mälardalen University, Västerås, Sweden

Supervisor: Iliar Rabet

Mälardalen University, Västerås, Sweden

Abstract

Table of Contents

1.

Introduction ... 4

2.

Background ... 5

3.

Related Work ... 9

4.

Problem Formulation ... 12

5.

Method ... 13

6.

Ethical and Societal Considerations ... 16

7.

Implementation and testing ... 17

8.

Results and discussion ... 19

9.

Conclusions ... 24

10.

Future Work ... 25

11.

References ... 26

A.

Mptcp.py Code ... 28

1. Introduction

2. Background

2.1. Internet of Things

2.2. Wireless Sensor Networks (WSN)

2.3. Transmission Control Protocol (TCP)

2.4. Multipath Transmission Control Protocol (MPTCP)

2.5. IEEE 802.11 protocol

2.6. Mininet and Mininet-WiFi

3. Related Work

3.1. Towards WiFi Mobility without Fast Handover

3.2. How Far Can We Go?

3.3. Energy Constrained Multipath Routing in Wireless Sensor Networks

3.4. TCP and MPTCP Retransmission Timeout Control for Networks

Supporting WLANs

3.5. QoS Evaluation of MPTCP over a Multi-Hop Wireless Network for IoT

Devices

4. Problem Formulation

5. Method

5.1. Experiment and literature study as method

5.2. Development Environment

5.3. Implementation

5.4. Network testing

6. Ethical and Societal Considerations

7. Implementation and testing

7.1. Prerequisites

7.2. Mobility

7.3. Testing metrics

7.4. Testing on the network