Performance of Multicast over Unicast in Wi-Fi

Transcription

1 Performance of Multicast over Unicast in Wi-Fi Ruben Groot Roessink University of Twente P.O. Box 217, 7500AE Enschede The Netherlands ABSTRACT This paper describes research on a suggested Multicast over Unicast (MoU) protocol as a possible improvement to (legacy) Multicast from the WLAN standard. This research measures performances of Multicast over Unicast and Multicast, to prove that the former performs better under certain circumstances than the latter. The research concludes that MoU has certain advantages over (legacy) Multicast, but that it is far from being standardized. The measured results concluded that Multicast over Unicast has less packet loss compared to (legacy) Multicast under the same conditions, but this was only measured under some different circumstances. Keywords Multicast, Unicast, Wi-Fi 1. INTRODUCTION This paper will describe the results and conclusions of a research on the performance of a proposed substitute for (legacy) Multicast protocol within Wi-Fi networks. In short, Multicast is slow, because it works on low bit rates and the packets are not guaranteed to arrive at all the nodes the packets were sent to, because Multicast makes no use of Wi-Fi s acknowledgment mechanisms. This paper describes a research which tries to explain whether the proposed Multicast over Unicast in theory can be a substitute to (legacy) Multicast within Wi-Fi. The research was conducted by doing measurements of both Multicast and Multicast over Unicast in order to be able to make any conclusions. The introduction of this paper consists of a part with an explanation of the terms further on, a part in which research questions are formulated, a part on work related to the research and a proposed research method. The following chapter describes in full detail how the actual measurements were conducted. Chapter 3 of the paper gives the results of the measurements, which are discussed in Chapter 4 and concluded in Chapter Background The research is conducted with certain knowledge on terms within the field of Wireless networks. The following terms Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. 27 th Twente Student Conference on IT July 7 th, 2017, Enschede, The Netherlands. Copyright 2017, University of Twente, Faculty of Electrical Engineering, Mathematics and Computer Science. are needed further on in the paper and therefore should be understood before reading on. Unicast, Multicast, Broadcast - Unicast, Multicast and Broadcast are the connection types. They are used within all kinds of networks, but always on the second layer or link (Wi-Fi) layer of the OSI Reference Model[7]. This paper specifically uses them in the context of Wireless Local Area Networks (WLAN). Unicast is a one-to-one connection, meaning a connection from one node in a network to another node in a network. Unicast is the most used mechanism of sending data in Wireless networks as all normal UDP/TCP connections are one-to-one connections. Unicast implementations have acknowledgment mechanisms to ensure that all the packets that are send, will also be received, however, a small chance still exists that the packet is still not received after the amount of retransmissions becomes larger than the set Retry Count of the Wireless Access Point. Every packet has a certain identifier, so when the packet is received by the receiver, the receiver sends an acknowledgment back confirming that this particular packet has been received. Otherwise, if the sender does not get an acknowledgment, he sends the specific packet again, until he receives an acknowledgment. Because of the acknowledgments mechanisms, Unicast can work over high bit rates. Higher bit rates have a higher throughput speed, but are more likely to be influenced by noise as they need more (difficult) modulation schemes to get that amount of throughput. Lower bit rates work with less/easier modulation schemes[4] and are therefore less likely to be influenced by noise on the network. A packet is than lost, meaning that an acknowledgment is never send back. The sender thus never receives an acknowledgment and will try to send the packet again, until it receives an acknowledgment that the packet was received or until the Retry Count is met. Multicast is a one-to-many connection, meaning that data is send from one node in a network to a group of other nodes. The Wi-Fi standard does have a specified protocol for Multicast, within the aa WLAN standard[1], but this protocol is rarely implemented within consumer electronics. IP Multicast is described in RFC 1112[2]. Wi-Fi consumer electronics however do have an implementation for Broadcast, specifying a one-to-all connection within the network. Broadcast is mainly used to issue control messages and to send the SSID (or identifier) of the Wireless Access Point, to let all peers within the neighbourhood know that the specific Access Point exists. Multicast and Broadcast, by design, work at one of the base bit rates (or Basic Service Set rates) of the Wireless Access Point (WAP), as this increases the change of all packets being received by the receiving nodes. The Base Service Set rate is always (one of) the lowest bit rates supported 1

2 by the router and the protocol used. As mentioned earlier, packets sent on lower bit rates are less likely to lost as they are easier to process, due to their less difficult modulation scheme(s). Multicast has a protocol for acknowledgment mechanisms, suggested in the aa WLAN standard, the Group Addressed Transmission Service (GATS), but again, no implementation is available in consumer electronics and therefore is not available to the consumer market. RSSI - Signal strength is normally displayed as the Receive Signal Strength Indicator, or RSSI for short. This can be measured in dbm, which is the power ratio (in decibels) of the measured power to one milliwatt. It is a logarithmic scale calculated by measuring the amount of noise on a Wireless network. The value, when talking about Wi-Fi networks, has a value between -100 dbm (the minimum signal strength) to -10 dbm (the maximum signal strength), with -100 dbm indicating a bad signal strength and -10 dbm indicating a good signal strength.[6] RSSI values can sometimes be calculated by the electronics used, but because manufacturers differ on the actual formula they use, it is key to the research to use the same electronics, or to measure from one central device (the WAP), thereby eliminating the possibility that test results are biased due to difference in formulas used. 1.2 Research purpose and questions This paper will contain a research on a proposed implementation of Multicast: Instead of sending data via Multicast to all peers within a Multicast group, is it not possible to send the data to the peer with the lowest signal strength and tell all other nodes within the Multicast group to listen to the connection between the sender and the peer with the lowest signal strength, and, if so, to what extend are all packets received by the listening nodes? The proposed Multicast over Unicast or MoU will be researched by measuring the performance of both normal Multicast and Multicast over Unicast. The performance will be determined by comparing the packet loss per node within the network and the time needed to send/receive the same amount of data. By comparing the performances of both Multicast and Multicast over Unicast this research will try to determine whether the latter is a suitable replacement of the former. The research goal is to measure the performance of MoU and compare it to the current implementation of Multicast. I will try to verbalize an answer to the following research questions: To what extend can Multicast over Unicast be a suitable replacement of normal Multicast? I will try to answer the question above by answering the following sub questions: 1. What is the packet loss as a function of the difference in signal strength between peers in Multicast over Unicast? The goal of this research is not to design a standardizable protocol for Multicast over Unicast, but simply to measure its performance in contrast to (legacy) Multicast. That should be kept in mind when reading this paper. 1.3 Related Work A paper [5], written by Pablo Salvador describes the implementation and evaluation of Group Addressed Transmission Service (GATS), which was standardized in the IEEE aa standard. This paper is relevant for this research as it is the implementation and evaluation of Multicasting within the WLAN standard. Specifically, GATS was standardized as a of set of mechanisms to efficiently support video multicasting [5], but the standard can be used for any kind of Multicasting. The research conducted, concluded that the implementation of GATS significantly improved video transer of WLAN s. 1.4 Research Method Packet loss comparisons The first sub research question tries to formulate a function between the amount of packet loss and the difference in signal strength. The question will be split in specific parts to propose a research method in order to answer the research question. First of all, before we start the breakdown of the question, it is necessary, perhaps obvious, to state that the measurements will both include (legacy) Multicast and Multicast over Unicast. Packet loss is the loss of a packet, e.g. a packet was sent, but not received. To safely say anything on the amount of packet loss a percentage has to be calculated of the amount of packets received divided by the amount of packets sent. Packets received Packets sent 100% Because the packet loss of the peer which the Unicast data will be sent to is likely to be 0 packets, due to Wi-Fi acknowledgements all packets will arrive, the packet loss ratio of the Peer which will receive the Unicast data is less important than that of the other peer(s). Signal strength within the area of WLAN is normally displayed as RSSI, as stated earlier on in this paper, meaning that the RSSI values of every node will have to be recorded with every measurement to be able to answer the question accordingly. The following set up is proposed to research the aforementioned research question, an explanation on the setup will be given below. Figure 1. The proposed test set up To answer the aforementioned research question the following method is proposed: A Wireless Access Point is set up and two or more peers connect to the Wireless Access Point via Wi-Fi. For the test results to be valid it is necessary that the peers in the network at least all use the same Wireless network card to connect to the WAP, in order to ensure results are not influenced by better network cards. Because Microsoft Windows does not readily support Monitor Mode over Wi-Fi and because Linux makes it much easier to put a network interface in Monitor Mode it is proposed to use Linux as the Operating System. A sender peer is connected via cable (to ensure all packets are guaranteed to arrive at the Wireless Access Point) Then, a test run is composed of two parts. The two (or more) peers are put at different distances of the Wireless 2

3 Access Point. The first part is to measure the performance of (legacy) Multicast, by connecting to a Multicast address from the sender node and then to send packets to that Multicast address. A route from this Multicast address to the right network interface has to be enabled on the peers and then they need to be set up to listen to this Multicast address. Such a measurement is conducted an arbitrary amount of times without moving the peers, so that the signal strengths stay approximately the same. The measurement is done the same amount of times, but now with the sender and the receiver, which is the node with the lowest signal strength, connected over Unicast and sending the same amount of data. The other nodes have to have the right interface in Monitor Mode, to measure how many packets can be detected over the network, with the source being the sender node and the destination being the receiver node. All data should be send via UDP and not via TCP, as TCP has acknowledgments within the Transport layer, meaning that no proper packet loss can be measured. 2. CONDUCTED RESEARCH METHOD This part will describe the research method and especially how it was conducted in detail, as the used research method has already been described earlier on in the paper 2.1 Hardware This subsection will focus on the hardware used to conduct the research Wireless Access Point - The center of the proposed research method is a Wireless Access Point, as it is needed to simulate the Multicast and Multicast over Unicast data transfers. A D-Link Cloud Router N300 (DIR-605L) was available at the university and so it was chosen as the basis of the test set up. The D-Link Router has a user friendly User Interface, which allowed the researcher to get the IPaddresses of the nodes in the network (in order to connect to them via SSH) much easier. One disadvantage of this particular router is that it displays the signal strength of the connected peers in percentages and not in dbm values. As the router also does not allow for a SSH/Telnet connection in order to retrieve the dbm values from the operating system, this meant that the RSSI values had to be retrieved from the nodes themselves and that they would be used together with the signal strengths in order to get the results. To be able to conduct the same research as this paper describes, any encryption needs to be disabled on the Wireless Access Point, as otherwise no messages that make sense can be caught by a peer which is not connected to the Wireless Access Point. Nodes - For the nodes in the network Raspberry Pis were used. The Pis are lightweight and therefore easy to use, allowing for easy (re)placement of the nodes in the test setup, and the Pis are easy to configure, as re-installing the operating system is a 5-minute job. As operating system Raspbian version v7 was used. Raspberry Pis also allow for an easy test-set-up as they are cheap and easy to come by and are easily controlled via SSH. The Pis used are all model 2B. The Raspberry Pis all functioned accordingly, up to the point when measurements had to be carried out. The listening Raspberry Pi failed to catch packets when in Monitor Mode and other tests showed that the packets could be catched when using another device. It is worth noting that the Pi s all have to be on the same channel as the Access Point (Channel 11 during this research), but the Pi failed to show the packets even when in the right channel. It was decided to use another device to take the job of monitorer. It is not known why the Pi was not able to catch at least some packets, but it might be a problem with the throughput speed of the USB-bus the Wireless network card was connected to. Further research might be conducted why the Raspberry Pi was not able to catch the packets. Raspberry Pis model 3 could have been used for the measurements as they have a Wireless network card build into them by design. However, this might not have solved the problem that the Pis did not function in Monitor Mode. When a solution to the problem described above is found, it is better to use Raspberry Pis model 3 as this will delete a hardware component from the test set up, which could have influenced the test results. The device used for the monitoring was a HP laptop of type Elitebook 8570w with an Ubuntu (version 16.10) operating system booted from a USB stick. The same network card as the receiving Pi was used, as will be described below. Network interface - In order to conduct the research with Raspberry Pis model 2B, a wireless network interface had to be added to the research, as Raspberry Pis of model 2B do not have a wireless network interface on their own. Via the university, two TP-Link N600 TL-WDN3200 were available. The TP-Link wireless network cards were used by both the Pi and the laptop to ensure that the results would not be influenced by difference in network cards. 2.2 Software This subsection will focus on the software used to conduct the research iperf - iperf3 is a tool for active measurements of the maximum achievable bandwidth on IP networks. It supports tuning of various parameters related to timing, buffers and protocols (TCP, UDP, SCTP with IPv4 and IPv6). For each test it reports the bandwidth, loss, and other parameters [3]. It thus allows a node to connect to one or more nodes (via a Multicast address) and simulate data transfer, in order to conduct measurements. iperf can be downloaded from the repositories of Raspbian and Ubuntu. The Multicast measurements were conducted as follows: The iperf server function was opened both on the laptop and the Pi with the lowest signal strengts (-s option), told to work over UDP (-u), and they were bound (told to listen on) to the same Multicast address (-B option, Multicast address was used by this specific research). The Multicast address however, first had to be added to the list of routes on the Raspberry Pi (route add wlan0) in order to let the Pi know which interface to listen on. The iperf client function was opened on the sender Pi (-c option), told to work over UDP (-u), and it was bound to send to the Multicast address. The client function further was called with the -b option and 10m as parameter, to ensure all tests were conducted with a 10 MBits/s bit rate. The latter was needed, so that all test were conducted with the same conditions and only one variable (difference in signal strength) would be measured. The Multicast over Unicast measurements were conducted as follows: The iperf server function was opened on the Pi with the 3

4 lowest signal strength from the Wireless Access Point and told to work over UDP (-u). It was bound to the IP address of its Wireless network interface (in the case of the Pi the wlan0 interface). The -c option was used to connect over Unicast to the IP address of the sender Pi. The iperf client function was opened on the sender Pi, told to work over UDP (-u) and bound to the IP address of its internal eth0 network interface (to ensure all packets will at least arrive at the Wireless Access Point). It was tasked to send the packets to the IP address of the other Pi within the test set up (after the -c option). Also this test was conducted with the bit rate set to 10 MBit/s. During both tests, the signal strengths (in percentage) recorded from the Wireless Access Point, the signal strengths (in dbm) were recorded from the peers/network interfaces and then the packet loss was noted down as reported by iperf. iperf has a clear output, telling how many packets were lost. Wireshark - Wireshark was used on the laptop in order to capture which packets were picked up via Monitor Mode when measuring the performance of Multicast over Unicast. It allows the user to capture and filtering all network traffic within a certain range from an user friendly Graphical User Interface (GUI) (but also without). The specific filter used, meant that only the packets with the right source address, the right destination address and only UDP packets would be measured. TCPdump - Wireshark could not be installed on Raspbian and so the decision was made to take network captures on the Pi s via TCPdump. It has almost the same functionalities of Wireshark, it only does not have a Visual Environment, but because the Pi s were installed without a GUI, this was not a problem. 2.3 Variables This section will focus on the variables of the measurements used when conducting the research Line-of-sight - The research asks itself if an actual Multicast over Unicast connection might have the same or even better results than a normal (legacy) Multicast connection and therefore if an Multicast over Unicast standard can function as a suitable replacement of (legacy) Multicast. It was decided to work with a line-of-sight to make sure the research questions would not become too difficult to answer within the scope of the research. Parameters as the degree in which the nodes differ in a direct line with the Wireless Access Point would have overcomplicated the research. All Wireless network card therefore were placed in a direct line with each other and the Wireless Access Point. 3. RESULTS The measurements were conducted both three times for Multicast and three times of Multicast over Wi-Fi. Measurements were conducted with the Pi always approximately 4 meters from the Wireless Access Point and the laptop at 0, 2 or 4 (on the same distance from the WAP as the Pi) meters from the WAP. 3.1 Multicast First of all, Multicast showed significant amounts of packet losses. All of the measurements showed that at least 60 percent of the packets were not received. All (legacy) Multicast tests were conducted only with iperf, meaning that it was possible to just read the amount of packet lost. The following part will describe per (legacy) Multicast measurement what the results were and 4 meters from the WAP in Table 1: 1 Pi, 4m 71% -42 dbm Laptop, 0m 100% -30 dbm Pi, 4m 70% -42 dbm Laptop, 0m 100% -34 dbm Pi, 4m 76% -44 dbm Laptop, 0m 100% -28 dbm Pi, 4m 73% -44 dbm Laptop, 0m 100% -28 dbm Pi, 4m 68% -45 dbm Laptop, 0m 100% -26 dbm Avg Pi 71.6% dbm Avg Laptop 100% dbm Table 1. Multicast results, nodes at 0 and 4 m First of all, it is important to note that for some reason, the iperf measurement did not finish on the Pi (probably because a out-of-order packet was never received or was dropped, signalling the end of the test) 4 out of the 5 measurements, namely measurements 1, 2, 3 and 4. To be able to get a packet loss, I calculated the packets received until the last snapshot and divided it by the total packets sent at the moment of the last snapshot as value between 0 and 1. Packets received Packets sent The packet sent was calculated by dividing the total number of packets which were sent (always 12756, with the last being out-of-order, which was a packet with a much higher id, to signal the end of the simulation) with the time spend. If the simulation would end on the Pi after 12 seconds and not further information was received, this meant that the value was calculated by dividing with 15 and multiplying it with 12 (10204) and 4 meters from the WAP in Table 2: 1 Pi, 4m 75% -48 dbm Laptop, 2m 80% -36 dbm Pi, 4m 73% -47 dbm Laptop, 2m 81% -35 dbm Pi, 4m 71% -48 dbm Laptop, 2m 76% -37 dbm Pi, 4m 75% -48 dbm Laptop, 2m 78% -37 dbm Pi, 4m 76% -47 dbm Laptop, 2m 80% -38 dbm Avg Pi 74% dbm Avg Laptop 79% dbm Table 2. Multicast results, nodes at 2 and 4 m It is important to note that none of the measurements on the Pi finished. 4

5 and 4 meters from the WAP in Table 3: 1 Pi, 4m 68% -46 dbm Laptop, 4m 73% -43 dbm Pi, 4m 65% -46 dbm Laptop, 4m 73% -43 dbm Pi, 4m 70% -45 dbm Laptop, 4m 75% -42 dbm Pi, 4m 70% -46 dbm Laptop, 4m 76% -41 dbm Pi, 4m 65% -45 dbm Laptop, 4m 71% -43 dbm Avg Pi 67.6% dbm Avg Laptop 73.6% dbm Table 3. Multicast results, nodes at 4 and 4 m It is again important to note that not all measurements on the Pi finished, namely measurements 3 and 5. The first thing that stands out is that I expected that the laptop would perform better than the Raspberry within (legacy) Multicast. Not because the laptop has better hardware, the same wireless network card was used, but because the laptop during every measurement was closer to the Wireless Access Point and therefore would show better results. In every test the Pi almost had the same packet losses, which was to be expected as the Pi stayed at the same distance (4 meters) from the Wireless Access Point. The laptop was placed at different distances of the Wireless Access Point, but the average measured packet losses differed only 3.5%, which is not significant. The reason that distance does not seem to have significant influence on the amount of packet losses might be that Multicast works on lower bit rates. Packet loss on lower bit rates is less than on higher bit rates as the modulation schemes used on lower bit rates are less difficult and so packets are less influenced by noise on lower bit rates. I do conclude that the packet loss on (legacy) Multicast is unacceptably high. The lowest packet loss is 74% at just 2 meters from the Wireless Access Point within a direct line-of-sight. The Figure 2 shows the measured Signal strengths in percentages plotted against the RSSI values. Because the Signal strength, shown by the router, is probably based on RSSI values, a relation between them might be drawn up. We also see in the graph that the signal strengths/rssi values of the laptop strongly decrease with a larger distance. The graphs makes me conclude that both RSSI and Signal strengths can be used in our function. 3.2 Multicast over Unicast Multicast over Unicast did not allow for the signal strength to be recorded, as the peer was not connected to the Wireless Access Point, but rather in Monitor Mode, to catch all the traffic in the direct neighbourhood. The RSSI value however could be recorded from the Wireshark capture, as the RadioTAP header displays the SSI Signal and 4 meters from the WAP in Table 4: The measurements in Table 4 were was not conducted at the same moment in time as the others, but the following morning, which might explain the somewhat higher aver- Signal strength (%) RSSI (dbm) Pi (4 (and 0) meters) Laptop (0 (and 4) meters) Pi (4 (and 2) meters) Laptop (2 (and 4) meters) Pi (4 (and 4) meters) Laptop (4 (and 4) meters) Figure 2. Signal strength (%) to RSSI (dbm) ratio 1 Pi, 4m 65% -49 dbm 0 Laptop, 0m dbm Pi, 4m 65% -48 dbm 0 Laptop, 0m dbm Pi, 4m 66% -47 dbm 0 Laptop, 0m dbm Pi, 4m 65% -47 dbm 0 Laptop, 0m dbm Pi, 4m 66% -45 dbm 0 Laptop, 0m dbm Avg Pi 65.4% dbm 0 Avg Laptop dbm Table 4. MoU results, nodes at 0 and 4 m age packet loss (because more routers might use the same channel at another moment in time) and thus more packets might be received when in Monitor Mode, resulting in more packet loss. All measurements above had a data rate or bit rate of 24 Mb/s and 4 meters from the WAP in Table 5: All measurements in Table 5 had a data rate or bit rate of 24 Mb/s and 4 meters from the WAP in Table 6: All measurements in Table 6 had a data rate or bit rate of 24 Mb/s. First of all, as mentioned earlier, the tables above display no Signal strength for the measurements done with the laptop. The Wireless network card was in Monitor Mode and therefore not connected to a Wireless Access Point. 5

6 1 Pi, 4m 70% -48 dbm 0 Laptop, 2m dbm Pi, 4m 73% -48 dbm 0 Laptop, 2m dbm Pi, 4m 76% -48 dbm 0 Laptop, 2m dbm Pi, 4m 73% -47 dbm 0 Laptop, 2m dbm Pi, 4m 76% -46 dbm 0 Laptop, 0m dbm Avg Pi 73.6% dbm 0 Avg Laptop dbm Table 5. Multicast results, nodes at 2 and 4 m 1 Pi, 4m 70% -44 dbm 0 Laptop, 4m dbm Pi, 4m 70% -44 dbm 0 Laptop, 4m dbm Pi, 4m 68% -46 dbm 0 Laptop, 4m dbm Pi, 4m 66% -46 dbm 0 Laptop, 4m dbm Pi, 4m 66% -46 dbm 0 Laptop, 4m dbm Avg Pi 68% dbm 0 Avg Laptop dbm Table 6. Multicast results, nodes at 4 and 4 m Because it was not connected, no measurement could be conducted what the Signal strength in percentages value was (a value only displayed on the Wireless Access Point and only assigned to connected devices) as a measurement of this value has to be done from the Access Point. The RSSI values could be measured from by extracting the (R)SSI Value from the RadioTAP header of the Broadcast messages of the Wireless Access Point. The second thing we notice is that all packets arrived at the Pi, because of the acknowledgments of Unicast. No packet loss occured. The most important result we encountered was that the laptop proved indeed to be able to catch a lot more packets than with (legacy) Multicast. Packet losses are more in the order of magnitude of 10 to 30 percent than 70 to 90 percent, as were measured earlier. What needs to be noticed is that the laptop did catch more packets over UDP with the right source IP address and destination IP address, which can be explained due to the acknowledgment mechanisms of Unicast. Packets are send more than once when the sender does not receive an acknowledgment of the receiver and these packets which were send again were catched by the network interface of the laptop in Monitor Mode. The duplicated packets were filtered by first exporting only the UDP packets with the right destination and source IP address with Wireshark. Then they were filtered by TShark, which is a command line network analyzer which comes with Wireshark, on the command line of a HP Elitebook 8750w laptop running Windows 10, to only export the data field of the packets, as iperf sends packets which have an identifier in the first 4 bytes of the data field. The duplicated packets were exported by a simple Python script, ignoring white lines and counting all non-duplicate packets. These amounts were then used to calculate the values in the tables and not the displayed packets, filtered by UDP, and IP addresses, in Wireshark. Because the first Multicast over Unicast measurement (with the laptop next to the Wireless Access Point and the Pi at 4 meters from the WAP) was conducted at another moment in time (the morning after the other two) it can not be concluded if packet loss increases over distance, which is a trend seen in the other measurements. 4. DISCUSSION 4.1 Test setup The test setup was a decent setup to test the direct lineof-sight capabilities of Multicast over Unicast over short distances, in order to answer the question if it works on larger distances. It should also be researched how well it reacts to other data on the network before being a good fit for being deployed on festivals for multiple video streams. However, the test setup did not account for objects between the WAP and the nodes in the network or a nondirect line-of-sight setup. Before being able to conclude whether Multicast over Unicast is a suitable replacement for Multicast, we first need to ensure that it also functions better under the aforementioned circumstances, and not only in the direct line-of-sight setup. Another factor which should be taken into account is that more and more routers use some kind of beam forming. Beam forming is used in newer Access Points to make the signal stronger in the direction of certain nodes in the network, instead of emitting circular waves in all directions. The effects of beam forming were not tested during this research, but using beam forming could influence the results significantly when the listener node is on the other side of the Wireless Access Point as the receiver node. 4.2 Results The results were maybe not that many, but the results that were measured allowed for at least some promising conclusions. To conclude whether Multicast over Unicast can be a substitute to (legacy) Multicast more research is conducted. The results of this research were too little to make significant conclusions like that. 4.3 Further work I will not go into the theories that much, because that is not important to this research, but further research might be conducted on the following subjects. Pi in Monitor Mode - Why was the Pi not able to capture any packets in Monitor Mode and therefore the suggested test setup became not workable. A possibility might be that the Pi, because it does all its calculations on the processor, might not have had enough throughput on the USB bus and so all packets were dropped. The effects of Beam forming - As described earlier on in this discussion, Beam forming might pose a problem to a possible Multicast over Unicast protocol, as this increases the chance of packet loss when the nodes are at two opposite sides of the Wireless Access Point. A full Multicast protocol should at least be able to handle different placements of the nodes in the network in relation to the Wireless Access Point. Whether Beam forming really poses a problem or not might be subject to another research. 5. CONCLUSION RSSI and signal strength both form a possible variable in an equation/formula. Their relationship is not a one- 6

7 value-to-another-value mapping, but overall we can state that the signal strength/rssi value decreases over distance. The tests were conducted at roughly the same time and thus were probably not influenced by other (environment) variables. Also, the Multicast over Unicast and (legacy) Multicast were conducted alternately, so is even less likely that the environment variables changed. Multicast over Unicast proves to have better results than (legacy) Multicast. Not only because one peer in the network now receives all the packets, due to the acknowledgments mechanisms of Unicast, but more packets are also received by monitoring nodes in the network. Multicast over Unicast is still not that reliable as still 10 to 30 percent of the packets are dropped over a maximal distance of 4 meters with direct line-of-sight. Direct line-of-sight means that the results might be more positive because, when an actual Multicast over Unicast implementation is used in a home network, walls and other objects greatly decrease the signal strength of a device to the Wireless Access Point, with direct line of sight we saw a decrease of 20 dbm or 20% decrease. An actual standard for Multicast over Unicast works better than (legacy) Multicast, with the same variables, in terms of reliability of packet loss. It probably will not be a good standard to be used in home networks, as no Multicast implementation is necessary to let home networks function as they do right now. A Multicast over Unicast protocol might be of good use when streaming video to multiple destinations, as not all packets are needed to be received to have a functioning video stream. These video streams might be used at festivals, where the video screens are high enough to have direct line-of-sight, to ensure the amount of packets received is enough for the stream to function. However, more research should be conducted on Multicast over Unicast over large distances. As stated earlier this research will not try to design a possible Multicast over Unicast standard, but it will suggest a very abstract possible protocol. For Multicast over Unicast to work, the peer with the highest RSSI value has to be sent a message that it will receive the Unicast stream and that it has to send acknowledgments to let the sender know that all packets are received by the receiver. This can be done using a normal TCP handshake. Then a message must be send to the specific Multicast group is about to send data. I suggest that at least this packet is acknowledged by at least one other peer in the network before starting to send the data. Then these peers will somehow try to catch all the packets with the peer with the lowest RSSI value as the destination IP address. introduction to mobile networks and mobile broadband, revised second edition. page 160, [7] H. Zimmerman. Osi reference model - the iso model of architecture for open systems interconnection. IEEE Transactions on Communications, 28(4), April REFERENCES [1] Part 11: Wireless lan medium access control (mac) and physical layer (phy) specifications. IEEE Amendment aa, [2] S. Deering. Host extensions for ip multicasting. IETF Network Working Group, August [3] iperf. iperf - the ultimate speed test tool for tcp, udp and sctp. June [4] L. L. Peterson. Computer networks, a systems approach, fifth edition. page 136, [5] P. Salvador. A first implementation and evaluation of the ieee aa group addressed transmission service. ACM SIGCOMM Computer Communication Review, 44(1):1 6, January [6] M. Sauter. From gsm to lte-advanced: An 7