• No results found

Application for selection of Bluetooth or WLAN

N/A
N/A
Protected

Academic year: 2021

Share "Application for selection of Bluetooth or WLAN"

Copied!
57
0
0

Loading.... (view fulltext now)

Full text

(1)

Degree Thesis

HALMSTAD

Computer Engineer, 180 credits

Application for selection of Bluetooth or WLAN

Degree Project in Computer Science and Engineering 15 credits

Richard Jönsson, Jonatan Svenjeby

(2)
(3)

Preface

The project has been both educational, interesting and fun which has contributed for both of us to a step closer to the work career in the data engineering field. It has also showed how much there is to learn about subjects surrounding this project.

We would like to thank our supervisors at HMS Bengt Eriksson and J¨orgen P˚alsson for the opportunity and support to accomplish this project. We also want to thank our supervisor Alexey Vinel at the University of Halmstad for the guidance and encouragement.

Jonatan Svenjeby and Richard J¨onsson

(4)
(5)

Abstract

Wireless communication is important in data transportation between devices. It is as ever important to find the best connection fitted for the users specific requirements. This process can be a hassle and having an application testing all the options could save both time and resources. This project involves solving mentioned problem and to create an application implementing the solution.

A method of recommending a connection is to measure different metrics e.g throughput and packet loss for Bluetooth (BT) and each channel on 2.4GHz and 5GHz Wireless Area Network (WLAN). By using an appropriate algorithm to rate the connections a result ranging from best to worst can be displayed to the user. Limitations on metrics can be inputted by the user to tailor the result to match user requirements.

The application is based on Hardware Meets Software (HMS) product Anybus Wireless Bridge II. With a Telnet connection Attention-commands (AT-commands) can be used to configure and utilize the modules e.g measure signal strength. Third-party services POCO and iPerf are used to measure other metrics e.g throughput and latency. C++ and Visual Studio was used to develop the application.

In accordance to the test specification the projected resulted in a successfully working ap- plication. Tests prove that with interference on a channel results in a worse rating and that other channels that are unaffected gets a higher ranking on the list. There is still room for improvement regarding exception handling when connection timeouts happen due to loss of signal.

(6)
(7)

Contents

List of Figures List of Tables

1 Introduction 1

1.1 Motivation . . . . 1

1.2 Purpose . . . . 1

1.3 Goal . . . . 2

1.4 Limitations . . . . 2

1.5 Problems . . . . 2

1.6 Specifications . . . . 2

2 Background 3 2.1 Bluetooth . . . . 3

2.2 WLAN . . . . 3

2.2.1 Wi-Fi . . . . 3

2.2.2 2.4 GHz . . . . 4

2.2.3 5 GHz . . . . 4

2.3 Anybus Wireless Bridge II . . . . 4

2.4 Factors . . . . 4

2.4.1 Network load . . . . 5

2.4.2 Interference . . . . 5

2.4.3 Packets . . . . 6

2.4.4 Number of nodes . . . . 6

2.4.5 Distance . . . . 6

2.5 Metrics . . . . 6

2.5.1 Throughput . . . . 7

2.5.2 Signal strength . . . . 7

2.5.3 Packet loss . . . . 8

2.5.4 Latency . . . . 8

2.6 Telnet . . . . 9

2.6.1 AT-commands . . . . 9

2.7 Programming language, tools and libraries . . . . 9

2.8 Related work . . . . 10

3 Method 11 3.1 Setup . . . . 11

3.2 Testing performance . . . . 11

3.2.1 Throughput . . . . 12

3.2.2 Signal strength . . . . 12

3.2.3 Latency . . . . 12

3.2.4 Packet loss . . . . 13

3.3 Implementation . . . . 13

3.3.1 Algorithm . . . . 13

(8)

3.3.2 Application . . . . 13

3.4 Programming language, tools and libraries . . . . 13

3.5 Testing and verification . . . . 14

4 Results 15 4.1 Anybus Wireless Bridge II and PC configuration . . . . 15

4.2 Testing the performance . . . . 15

4.2.1 Throughput . . . . 15

4.2.2 Signal Strength . . . . 16

4.2.3 Latency and packet loss . . . . 16

4.3 Algorithm . . . . 16

4.3.1 Selected algorithm . . . . 18

4.4 Application . . . . 18

4.5 AT-commands and Telnet . . . . 22

4.6 Test . . . . 23

5 Discussion 27 5.1 Algorithm . . . . 27

5.2 Application . . . . 27

5.3 Results . . . . 29

5.3.1 Metrics . . . . 29

5.4 Social requirements . . . . 30

5.5 Related work . . . . 31

6 Conclusion 33 6.1 Experience . . . . 33

6.2 Continuation of development . . . . 33

6.3 Results . . . . 33

References 35

Appendices 37

A Requirement specification 37

B Test specification 40

C Flow chart 45

D UML diagram 46

(9)

The following figures 1, 9 belongs to HMS.

List of Figures

1 Anybus Wireless Bridge II . . . . 5

2 Setup of the system . . . . 11

3 Part of the JSON data to parse from . . . . 15

4 Example of user input . . . . 19

5 Different outputs from the application. . . . 20

6 Two plots made with Matlab . . . . 21

7 Two different AT-commands to set and get the current AP channel . . . . . 22

8 AT-command sent to the module and response parsed . . . . 22

9 Web interface of the AWBII . . . . 23

10 LEDs indication layout on the AWBII . . . . 23

List of Tables

1 Example of algorithm 1 . . . . 17

2 EMC chamber test results. w/o (without) w/ (with) . . . . 24

3 Packet size test . . . . 25

4 Test on overlapping channels . . . . 25

(10)

Abbreviations

• AP - Access Point

• API - Application Program Interface

• AT-commands - Attention-commands

• AWBII - Anybus Wireless Bridge II

• BNEP - Bluetooth Network Encapsulation Protocol

• BT - Bluetooth

• ICMP - Internet Control Message Protocol

• IoT - Internet of Things

• L2CAP - Logical link control and adaptation protocol

• MTU - Maximum transmission unit

• NAP - Network Access Point

• OSI-model - Open Systems Interconnection model

• PAN - Perosnal Area Network

• PANU - Personal Area Network User

• RSSI - Received Signal Strength Indication

• RTT - Round-trip time

• SRD - Short Range Device

• TCP - Transmission Control Protocol

• UDP - User Datagram Protocol

• WLAN - Wireless Local Area Network

(11)

1 Introduction

End to end communication is a widely used method for communicating between different devices and to this there are several approaches. Commonly this is done through a cable between interconnected devices. These cables can transfer various information for different end usage. Information transferred could be video data, raw data or some sort of data that enables communication between two devices. At an industrial point of view it could be important to send data from a device to another like sensor readings in need of processing.

In an industrial environment where a lot of devices need to send data there can be several downsides with the cables connecting them e.g cable management, accessibility and cost.

Wireless communication is another means for communication without the hassle of cable management as well as being more accessible and scalable. There exist several wireless technologies with different implementations and their own ideal usage fields. Some of these, which are also relevant to this project are WLAN and Bluetooth.

HMS is a company that specialize in industrial communication and industrial Internet of Things (IoT). Their product Anybus Wireless Bridge II (AWBII) connects wired devices through serial or Ethernet to transfer data wireless over WLAN or Bluetooth and thus re- placing the need of cables. With devices that implements several wireless communication technologies, comes decisions about which one to use under which circumstances and envi- ronments. Since different technologies have different strengths and weaknesses, that decision isn’t always obvious. By having an application making relevant measurements and calcu- lations the decision can be narrowed down to simple options like preference regarding e.g throughput, latency or signal strength.

1.1 Motivation

At cable replacement it’s important to select the best applicable wireless technology. In addition to data transfer requirement the radio environment with different disturbances has impact on performance. By use of multi-radio modules the selection of wireless technology can be done when the modules are installed. An application is useful as a help to make the best selection of Bluetooth or WLAN.

1.2 Purpose

To investigate different methods of testing factors of a wireless communication technology.

Look into different algorithms of recommending the most suitable wireless communication technology between WLAN and Bluetooth. A suitable connection depends on user inputted parameters and factors like network load and interference.

(12)

1.3 Goal

The goal is to define a method of recommending WLAN or Bluetooth. And to create an application that is capable of recommending the most suitable wireless connection technology.

User input will influence the outcome of the algorithm.

1.4 Limitations

The application will due to technical difficulty and too wide of a scope for this thesis, not take distance as a parameter. Number of modules will be limited to two Anybus Wireless Bridge II, since these will be sufficient to solve the problem. However both distance and the number of modules and their impact on the selection of wireless technology will still be discussed in the thesis. Configuration and application process is restricted to the functions available for Anybus Wireless Bridge II.

The report may skip some details that deems to affect the secrecy of HMS and their products.

1.5 Problems

• How to define an algorithm to recommend when Bluetooth or WLAN is best for data transfer based on the following requirements: interference, signal strength, latency, throughput, packet size and packet loss.

• How to verify that the algorithm works.

• How to implement a solution as an application on PC.

• How to connect a PC to Anybus Wireless Bridge II through Telnet and use AT- commands to configure them.

1.6 Specifications

An application will be created to implement the algorithm of recommending Bluetooth or WLAN. The application should be able to take input from the user in form of parameters.

These parameters i.e packet loss, throughput, latency, interference and signal strength will affect the outcome of the recommendation of Bluetooth or WLAN. All the factors will be measured with the help of AWBII. A PC will be used to run the application and connect to AWBII.

A requirement specification was written in collaboration with HMS to give an understanding on what should be done to achieve the goal of the project. A test specification was written to confirm that the requirements stated in the requirement specification is fulfilled. Requirement specification can be found in the appendix A.

(13)

2 Background

This chapter will present all information gathered during the pre-studies phase of the project.

Topics like Bluetooth, WLAN and factors that influence performance will be discussed.

2.1 Bluetooth

Bluetooth (BT)[1] is a wireless technology used for short range exchange of data. Standard- ized under Institute of Electrical and Electronics Engineers (IEEE) 802.15.1 and uses the 2.4GHz frequency band. IEEE is an organization and association working toward develop- ment of different technologies. BT communication networks uses master/slave architecture where one acts as a master that controls up to 7 slave devices. This is called a piconet. The slaves can only communicate with their master and the master sets up the communication in synchronized fashion for an almost non-collision and interference free way. Bluetooth uses a method called frequency-hopping spread spectrum where it performs up to 1600 hops per second between 1MHz (or higher) bandwidth channels to ensure that it uses a channel that won’t interfere with other devices. There are several versions of Bluetooth with latest being 5.0 which is backwards compatible. New versions introduce new functions as well as improved power efficiency and data throughput.

2.2 WLAN

Wireless Local Area Network (WLAN) is a wireless computer network using wireless com- munication to form a Local Area Network (LAN). As with regular LAN, WLAN can be connected to other networks and have a gateway to the internet. WLAN implements the IEEE 802.11 standard which employs different protocols to enable wireless communication and is often called Wi-Fi.

2.2.1 Wi-Fi

Wi-Fi is a type of wireless communication technology used by devices to communicate wire- lessly. Wi-Fi is the name given to the IEEE 802.11 standards by the Wi-Fi Alliance, thus having a device with Wi-Fi describes that it contains a Wi-Fi chip which uses the IEEE 802.11 standards. Some examples of the standards are IEEE 802.11a/b/g/n/ac and with each new standard comes new features and improvements such as higher throughput and better modulation techniques[2]. Newer versions are backwards compatible with older ver- sions of 802.11 but devices can be configured to only support selected version. In order for a device of an older version to connect to a network, all other devices must support that version.

Wi-Fi usually transmits over the ISM-bands (Industrial, Scientific and Medical band), which includes the most common bands, 2.4GHz and 5GHz. ISM is internationally acknowledged to be a licence free spectrum, which means that transmissions is available to anyone.

(14)

2.2.2 2.4 GHz

The 2.4GHz band is the most widely used frequency band and is implemented by 802.11b/g/n.

In Europe it contains 13 overlapping channels with each having a bandwidth of 22 MHz and 5 MHz in between[3]. There are different sets of three of non-overlapping channels and the most used set is channels 1,6 and 11. Typical traits of the 2.4GHz band is its longer range and slower transfer rate. It’s also prone to interference due to it being commonly used by Wi-Fi, its relatively large bandwidth and other devices like microwaves which uses the same frequency.

2.2.3 5 GHz

The 5GHz band is implemented by 802.11 a/n/ac and due to different restrictions worldwide it’s applications vary[4]. Overall it contains 23 non-overlapping channels with 20 MHz band- width each. There is the option to have a lower amount of channels with 40 MHz bandwidth, thus increasing transfer rate. In North America the frequencies between 5.725 GHz and 5.875 GHz, containing 5 channels are part of the ISM-band and available for everyone. In Europe these channels are limited to Short Range Devices (SRD) on 25 mW max power. As opposed to 2.4GHz its traits are shorter range and increased transfer rate.

2.3 Anybus Wireless Bridge II

Anybus Wireless Bridge II (AWBII, seen in figure 1)[5] is a product developed by HMS that acts as an industrial wireless connection solution for an industrial Ethernet network. The device is capable of using either WLAN or Bluetooth for wireless communication of an range up to 400 meters. The device supports several protocols like IEEE 802.11 (up to 802.11n) and BT 2.1 (Bluetooth classic). AWBII can be configured through AT commands, a web interface and easy setup with a button on the devices itself. The device can either be used as access point (AP) or client, to create a network or connect to an already existing network. By connecting the device to a machine, it becomes more accessible, lowers the overall risk when interacting with it and reduces cost due to less cables used. AWBII hosts a ODIN-W2 series Stand-alone multi-radio module. Maximum throughput for WLAN is 20Mbps and 1Mbps for BT on the AWBII. AWBII uses WPA/WPA2 security for WLAN and NIST compliant encryption algorithms for Bluetooth[6].

2.4 Factors

The following sub chapters will discuss either how factors can affect the performance of a network or each other. This is fundamental to understand in order to know how certain factors should be prioritized and why a selection of one wireless technology may be the better choice.

(15)

Figure 1: Anybus Wireless Bridge II

2.4.1 Network load

A wireless network has limitations on how much data can be sent in a single moment. All users on the wireless network shares the available bandwidth and contributes towards the maximum capacity while sending data. While the limit is reached throughput can be affected negatively. This is because a wireless network is set up on a channel and that channel has a certain frequency band which has physical limitations of how much data can be sent at a given time period. This isn’t a problem for wired devices because each device has it’s own dedicated wire which is not shared with other users of the same network. The devices handling the communication between devices can be a bottleneck of the network as it can only process a certain amount of data at a given time.

2.4.2 Interference

Interference comes in many different shapes. Interference could be collisions from nodes in a network that do not benefit from Carrier-sense multiple access with collision avoidance (CSMA/CA) due to the hidden node problem. Interference could also be frequencies received from different sources than the one intended, like nodes on other networks on overlapping channels or machinery operating on the same frequency band. A proof of interference in a network could be reduced throughput, packet loss and increased latency.

Interference can be measured in several ways, some being more accurate while others provide more of a general value. For a proper and accurate description of the radio environment a spectrum analyzer would be the ideal tool for measuring interference like the Ellisys Bluetooth Vanguard[7]. The downside is that this is an external tool and importing data into a PC and interpreting it can be a difficult task. The easier alternative would be to test latency, throughput and packet loss between two nodes directly which are three simple values that can be easily calculated.

(16)

2.4.3 Packets

When devices communicate over a network its data is sent in packets. Sizes of these packets vary and affects the network. Limitations in WLAN and BT allows different packet sizes and influences the choice of technology. Packet loss is often the result of interference, which in turn will affect throughput. Representation of packet loss is often done as a percentage of the total amount of packets sent. How data is transported with IP-protocol can affect the performance. User Datagram Protocol (UDP) favours throughput and latency but not packet loss and reliability. Transmission Control Protocol (TCP) favors reliability and less packet loss but not throughput and latency.

2.4.4 Number of nodes

Number of nodes refers to the amount of connections within a network. A network could have a lot of clients connected that affects the performance of the network. Performance is only affected if there are a lot of devices trying to communicate at the same time. For WLAN, one network shares the total bandwidth capabilities between all connected devices. WLAN also use modulation because of half-duplex restriction for communication which limits the time each device can communicate, which in term affects the performance for each client. BT also takes use of similar modulation which affects the overall performance of the network.

2.4.5 Distance

Distance is the physical range between two wireless devices in meter. Both BT and WLAN are susceptible to signal integrity. The distance of a wireless connection does not necessarily affect the performance, reliability and other factors directly, but the risk of encountering interference which does affect said things increases. According to Jason Block at HMS “A Fresnel Zone is an elliptical field that exists between a wireless transmitter and receiver, and must remain clear to prevent destructive interference with waves emitted from the transmitter”[8]. Thus it’s important that there is clearance for the signal as obstacles can degrade the signal strength and as well be more susceptible to interference while a signal is in the air. Radio or antenna capabilities may have constraints that can limit the possible signal strength which in turn decreases the possible communication distance.

2.5 Metrics

This chapter will discuss how metrics can be measured and how the result can be affected by the radio environment and above mentioned factors. These metrics will be used along with the algorithm to determine the most suitable connection for the user.

(17)

2.5.1 Throughput

Throughput refers to the amount of data being transferred in a second and is measured in bits per second (bps). It’s important to note that the actual transfer rate is most likely less than the theoretical throughput due to factors like interference from other traffic on the same network or connection speed. Factors like latency and the transportation protocol (TCP/UDP) also affect the overall throughput.

Throughput is often tested in a setup where one device acts as client and the other as a server.

The client send/receives data while the server receive/send data. It then give a representation of result to the client of how much data has been sent/received over the period of time of the testing or vice-versa. Iperf3 is an example of an application for testing throughput between two nodes. An alternative to running an Iperf3 application is to create a custom application with identical behaviour by creating a TCP/UDP server and client. Many programming languages like C++ have capabilities of socket programming that allows a client to send bytes of data over a network.

Throughput can be tested using TCP protocol to ensure the all the data is being sent even when the data is dropped or lost during transmission as TCP protocol will transmit the data.

Testing throughput with TCP will ensure in situation when exactly all data is required and in correct order is important. But this will however result in a lower overall throughput. The other option is to send with UDP protocol which prioritize latency for increased bandwidth but don’t ensure that all data has been sent and receive the in right order. Choosing what protocol to test throughput depends clearly on the sort of data being sent and their respective application use.

2.5.2 Signal strength

Signal strength or Received Signal Strength Indicator (RSSI) is a measurement used for determining the strength of a received signal from an external transmitter. A more accurate way to represent the RSSI is in miliwatt (mW) or decibel-milliwatts (dBm). A higher dBm indicates a stronger signal. Manufacturers usually represents the initial value as RSSI and convert it to dBm as it is more consistent [9]. A weak signal is more susceptible to interference and noise which results in increased packet loss and in turn a degraded overall throughput.

This is confirmed in a study where the performance was tested against RSSI values[10].

Obstructions can affect signal strength and it’s mostly dependent on the type of material and thickness of it thus it’s important to plan the network environment as obstruction clear as possible. Increased range between two nodes will impact the RSSI. Nearby signals in the same frequency spectrum also affect the signal strength[8].

RSSI is often available for both WLAN and BT on most devices. Reading the RSSI value depends on the manufacturer and the device. For AWBII, values can be read through AT- commands. The RSSI value can either be read one time or several readings over a period of time and averaged out. The RSSI value can sometimes shift rapidly and the downside with one time reading is that the RSSI value may be at its peak and not at its average. Averaging

(18)

out the RSSI value over a period time represent a more accurate reading but also increase the overall time it will take for the application to measure performance.

Link quality is an alternative to RSSI that give a sense of quality of the signal. Link quality measurement is only available for BT and not WLAN on the AWBII. Measurements done by HMS also indicates that link quality tends to stay at a better value for further distance than RSSI. This of course could affect the algorithm if BT used link quality instead of RSSI.

2.5.3 Packet loss

Ping/echo in the Internet Control Message Protocol (ICMP) is a common network utility to measure packet loss. A client send a certain amount of packets over a network to a remote node. The client then receive a response from the remote node of how many of packets were successfully received. This can be used by both WLAN and for BT if the Bluetooth Network Encapsulation Protocol (BNEP) protocol is used. Iperf3 also has the option when testing the throughput with UDP protocol to output packet loss for the sent datagrams.

2.5.4 Latency

Latency refers to the time for a packet to be sent from one node to another. This is an impor- tant metric in communications for industrial usage. Low latency can be more important for time critical applications than e.g throughput. Thus it’s important to have a understanding of how latency can be affected by other factors.

According to a study is latency affected by interference[11]. While using a baseline end to end latency around 700ms, the latency increased up to 2,2 seconds the more networks was active and the higher the throughput became. Due to Wi-Fi being half-duplex, implies that Wi-Fi can only send/receive one packet at the time. Wireless communication is therefore prone to both packet collision from hidden nodes and having to cancel the transmission of packets if it sense the channel is busy for transmission.

Indicated by a study, RSSI and airtime causes variations in latency. Wi-Fi hop latency was tested in different locations in University campus, the correlation between these factors and latency shows that a weak RSSI and long airtime increases the latency. The study proves further the correlation between high re-transmission of packets and increase in latency and as implied from the last paragraph the reason for this could be because of interference from nearby network device communications[12].

For BT, latency seems to not be affected of distance between two nodes but rather of the the amount of hops required. Although, the decreased RSSI reading in this test didn’t seem to either affect latency for BT[13].

Latency can be measured with a network utility called ping/echo from the Internet Control Message Protocol (ICMP) [14] which is part of the TCP/IP-model. Ping measures Round- trip time (RTT) between nodes in a network. BT supports the functionality of sending IP packets over a network because of the BNEP protocol. The protocol is part of the host

(19)

part of the BT stack[15] which lays above the Logical Link Control and Adaptation Protocol (L2CAP). L2CAP can pass packets sent between the controller stack and the other layers at the host stack. AWBII can be setup as a Perosnal Area Network (PAN) so that one act as Network Access Point (NAP) and the other as a Personal Area Network User (PANU).

TCP/UDP packets can then route through a BT connection and the ICMP protocol can be used for BT. Alternative to ICMP is l2ping [16], a tool that can be used for BT latency at the L2CAP protocol and is an alternative to ping with ICMP protocol.

2.6 Telnet

Telnet[17] is a protocol at the application layer of the Open Systems Interconnection model (OSI-model) used for text-oriented communication over a TCP/IP network. By connecting a PC to a remote host, a virtual terminal can be set up on the client’s PC that allows plain text information to be sent. This is useful to perform various functions on the remote machine for easy configuration without need of physical access.

2.6.1 AT-commands

Attention-commands (AT-commands) are commands used for controlling modems. AT- commands derives from a set of commands called Hayes commands that was used by Hayes smart modems. AT-commands are written in plain text and usually starts with AT followed by different symbols depending on the set of commands being used. Implementations of AT- commands varies between the manufacturers[18]. AWBII is able to receive AT-commands in two different ways. One is through a web interface which can be accessed on the default IP- address for the device. The other way is through Ethernet directly. A port can be specified that the AWBII can listen to. This way any application sending IP-packet on this port can send AT-commands over wired Ethernet.

2.7 Programming language, tools and libraries

C++ is a programming language with support for data abstraction, generic programming, object oriented programming and low level programming. It’s based on C but unlike C it also support classes like many other object oriented programming languages like Java.

Visual Studio is an Integrated development environment (IDE) for Windows. An IDE is software for writing code, it normally provides developers with a source code editor, build automation tool, and a debugger. Some IDEs, like Visual Studio and Eclipse, also comes with a compiler. Visual Studio can be used to build desktop applications using C++.

There are several libraries available for networking that can be used to measure metrics like latency, throughput and packet loss. Winsock is an Application Program Interface (API) included in Visual Studio. Iperf3 is a tool for measuring bandwidth. For it to measure bandwidth a server and client has to be set up. Iperf 3 has the alternative to use a data

(20)

structure called JavaScript Object Notation (JSON) to output it’s result. POCO is a smaller library with good documentation. It comes with an API for networking that provides many useful classes like ICMPClient which can be used to ping and measure packet loss. Boost is a very large and popular library with a wide usage but not as good documentation.

Wireshark is a network packet analyzer used for analyzing packets sent/received in a network.

This is an useful application that can be used to what is contained within packets e.g port numbers, data and destination.

2.8 Related work

There are several applications for mobile that have a similar functionality of determining the best WLAN channel, often based on overlapping channels and RSSI. The application display the results for the users in form of a rating which a user can use to plan their network setup at e.g. home and office. A dynamic channel assignment algorithm for IEEE 802.11 WLAN [19] is a paper describing an algorithm of selecting the most suitable channel for a WLAN connection. The paper mentions using one of these mobile application to gather e.g RSSI value for the algorithm. They propose that the algorithm could be used in future work to implement other wireless technologies like Bluetooth and ZigBee.

(21)

3 Method

This chapter describes different approaches for achieving the different goals of the project.

3.1 Setup

The application setup can be seen in figure 2. The PC named server is connected to AWBII through wired Ethernet connection. The specific wire used for this project is a CAT 5e with a RJ45 plug on one end for the PC and a 4 pin M12 contact for the AWBII. This AWBII is the AP (Access Point). The server PC hosts the application with the algorithm and testing of the performance. The performance is tested from the AP’s perspective and not the AWBII clients with the exception of signal strength. This is because the module acting as AP cannot use the AT-commands for receiving RSSI. Therefor is important to take this into consideration when implementing the application. Since an application can’t be installed on AWBII, the setup requires a client PC for measuring throughput as there isn’t any way to measure it without hosting an application on another device which receives the data. This PC will have Iperf3 installed which will send data to the server PC when testing the throughput. The other metrics can be measured without the presence of a client PC.

A minimal delay between the AP and server from the PC is introduced through the Ethernet connection. This delay is smaller than 1ms that is negligible and won’t be taken into consid- eration when testing the performance. When the throughput is tested it’s between the PCs and not between the modules directly.

Figure 2: Setup of the system

3.2 Testing performance

Description of how the different metrics will be tested. All metrics will be measured over a period of time for each channel on WLAN 2.4GHz, 5GHz and BT connections. The user has the option to specify which channels to test for WLAN 2.4GHz between 1-11 and 5GHz 36, 40, 44, 48. Since Bluetooth uses frequency-hopping, testing each individual channel is not necessary. If no specific channels/connections are chosen by the user the default channels will be 1, 6 and 11 for 2.4GHz and 36 and 48 for 5GHz and BT. For WLAN 2.4GHz and 5GHz the result will display for all selected channels. The protocol used by WLAN depends on the users on the network, but will most likely use 802.11n. The Bluetooth connection will use version 2.1.

(22)

3.2.1 Throughput

The throughput will be measured between two PCs as in figure 2. Iperf3 will be used to measure the throughput between the two PCs. At first it was considered using POCO and create a simpler application for the client PC whose job would be to send data to the server PC. But iPerf3 was chosen instead as HMS recommended it and had prior experience with it.

The server will receive data from the host during a span of time and when the transmission is done, it will calculate the throughput. The Maximum transmission unit (MTU) is specified by the user parameter ”packet size” and the default value is otherwise 1500 Bytes which is a standard value for Ethernet frames. TCP will be the chosen protocol for testing throughput as in industrial usage it’s often important to ensure that all data is received. To receive the result a JSON file is generated by iPerf 3 to be used by the application.

3.2.2 Signal strength

RSSI values for a connection are retrieved with AT-commands sent to AWBII. This RSSI value is a relative index describing the strength of the signal. The result of the AT-commands is an integer that will be used as a factor for determining the application outcome. The RSSI value read from the AWBII acting as a client will be used i.e the signal from the AP to the client. The reason it’s from the AP to client is because it was discovered that AWBII cannot measure RSSI as an AP. It’s taken into consideration that if roles of AP and client were switch, the RSSI readings could differentiate. The RSSI is collected several times over a period of time specified by the user and is averaged out for a more reliable value of RSSI since it can differentiate between every reading.

Link quality was initially planned to be used because AWBII lacked the required support for RSSI. But during the project an update on the modules firmware allowed access to this feature. Link quality will not be used as it would probably give BT better overall score for signal strength category which would not be a fair comparison to WLAN. As a result requirement nr 12 has been changed to accommodate this.

3.2.3 Latency

At first it was considered using l2ping or a similar solution that could be adapted into to the application. But after further look into the BT protocols, BNEP is able to send IP packets over a BT communication and thus it was chosen instead. This will be more convenient because most of the code for measuring latency can be used for both BT and WLAN. The latency is measured with the ping network utility from the ICMP protocol. Ping measure latency for WLAN and BT. For BT, PAN will be setup on the AWBII where one is a NAP and the other a PANU.

(23)

3.2.4 Packet loss

Packet loss will be measured with the ping network utility. ICMP packets are sent from the AP to a remote client (AWBII) which checks how many are lost during a period of time. The result will be displayed in percentage where a higher percentage indicates higher packet loss.

The size of the ICMP packets are specified by the user. The use of ICMP packets for testing packet loss works for both WLAN and BT as BT protocol have support for IP-packets.

3.3 Implementation

3.3.1 Algorithm

Several algorithms will be designed but will only given a basic description on how it works.

The algorithm that is chosen to be implemented will be given a more in-depth description.

None of the designed algorithms are intended to be optimal or ideal, but will serve as an example on how to rate a connection. The other alternatives serves as a backup if the initial algorithm does not work in practice.

3.3.2 Application

The application will consist of a command line interface (CLI) and will be created in Visual Studio. When the application starts the user will be presented with option of setting limits to the different metrics or choose to use default limits. The default limits are set to the lowest value possible for respective metric and won’t affect the output. Packet size and time limit has to be set by the user as well. After the measurement has finished, the results for throughput, latency, RSSI and packet loss will be displayed. The connections that didn’t pass any of the limit requirements will be printed out as well to show the reason they failed e.g. throughput for channel x didn’t reach the requirement.

3.4 Programming language, tools and libraries

Selection of programming language is an important part of the project and will affect how the final result will look like. What is expected of the language is that there are available libraries that support network programming and sending AT-commands with Telnet functionality.

The language should also be supported by tools that build graphical user interfaces.

The initial programming language choices was between C and C++. The choice came down to C++ for several reasons:

1. It is a high level language that supports some low level programming.

2. It has useful third party libraries that provides network programming.

3. Graphical user interfaces can be built in Visual Studio using C++.

(24)

The library POCO was selected as it proved from tests to be capable of sending AT-commands over a Ethernet connection and wireless, measuring both latency, and packet loss. POCO is decently documented and easy to follow with many useful classes. The latest version of Visual Studio 2017 is the selected IDE since it supports C++ coding, compiling and additionally provides tools for graphical user interface building. In order to use POCO library, Windows Software development kit (SDK) 8.1 had to be installed on the PC.

Iperf3 will be used to test the throughput between two nodes as it was suggested by HMS, since they also have prior experience with it. Iperf3 will run a standalone version on the client PC in figure 2 while the application running on the server PC will execute a shell command to run Iperf3 and connect to the client PC when needed.

3.5 Testing and verification

In order to check the application and it’s functionality, testing and verification is needed and will be done in accordance to the test specification. The specification will consist of cases that test that the algorithm chooses the right connection. Test cases will also be written for the command line interface. These tests will be done several times to ensure consistency.

Wireshark will be used to analyze packets sent during the different test to ensure that the packet size is correct and to get an overview of actual packets sent between nodes. It is planned that an EMC chamber will be used to create interference on spectrum bands that both Wi-Fi and BT operate on to test packet loss, throughput and latency values for WLAN and BT.

(25)

4 Results

The results of the different parts of the project are presented in this chapter.

4.1 Anybus Wireless Bridge II and PC configuration

Referring back to figure 2. The PCs run Windows 10 64bit version. The two modules both run the latest firmware. The two modules are configured to be able to reconnect to each other whenever they switch connection type or when the AP has to switch channel and restart.

Each module are connected to a PC via Ethernet cable. All four devices are within the same network and the only route between the PCs are the modules themselves. The PCs aren’t connected to any other external networks. The IP-addresses are static for all devices so it doesn’t change automatically during run time. The modules doesn’t have WLAN and BT enabled at the same time as it will create a loop back problem when routing IP-packets.

4.2 Testing the performance

4.2.1 Throughput

An instance of Iperf3 in server mode is started on the client PC in figure 2 before the start up of the application. The server PC starts a client instance of Iperf3 using ShellExecuteEx in C++. This is done with the corresponding parameters specified by the user which are time of test, packet size, port and remote server IP-address of the client PC. ShellExecuteEx is equivalent of starting the application with the help of a command prompt in Windows OS. The application wait for Iperf3 to finish its measurement and return a generated JSON file consisting of the measurement results. Part of the JSON output is seen in figure 3.

The application then use a JSON parser to find the object sum received, then the variable

Figure 3: Part of the JSON data to parse from

bits per second (seen in figure 3) and saves that value to be used in the algorithm. Iperf3 uses a TCP connection for the tests in reverse mode so the server instance of Iperf3 sends data to the client instance of Iperf3. Specifying the packet size for a TCP connection throughput

(26)

test doesn’t work. But it’s still present if future updates fixes the bug or if the application will run on a Linux distribution in the future. Iperf3.1.3 64bit version is used on both PCs.

4.2.2 Signal Strength

Signal Strength is measured by sending AT-commands to AWBII. If the connection currently being tested is BT, the AT-command string is AT*BRSS=0 where the zero indicates the handle of the connection to get the RSSI from. This is sent to the remote AWBII. Otherwise the AT-command is AT*WSRSS? for a WLAN connection. RSSI received by the modules is between -100 and -30.

4.2.3 Latency and packet loss

Both latency and packet loss are calculated simultaneously using the ICMP protocol. Using POCO ICMPClient made it possible to ping the host. With the use of a timer it sends one packet as many times as the timer allows. After each time, it calculates the RTT and packet loss and adds it to two different variables. These values is then divided by how many packets were sent, giving an average on RTT and packet loss. The ICMPClient object is implemented in a class called Ping, which executes the measurement with two functions returning the latency and packet loss values to be used by the algorithm.

4.3 Algorithm

The project group came up with the following three algorithms. The algorithms is based upon the following metrics: throughput, latency, signal strength and packet loss. Comparison on metrics will be between 2.4GHz, 5GHz WLAN and BT.

Algorithm 1: A simple point system for each metric tested. As an example parameters will be worth 1 point and preferred parameters will normally be worth 2 points. Only one preferred parameter can be set. Only the parameter whose metric gets the best measurement gets the point or if the metrics is within an interval of each other, they all get points. To the parameters are set minimum/maximum requirements and if a metric doesn’t meet this requirement, it wont get any points. If no parameter limit is set, then a parameter will receive points as usual. First, channels in a connection will be compared and rewarded points depending on the metrics. These channels will be regarded as representatives for 2.4GHz, 5GHz WLAN to be compared to each other and BT , and then be rewarded points depending on the metrics. Example as seen in table 1, a case is that channel 1 for 2.4GHz receives 3p, channel 11 for 2.4GHz 1p, channel 36 and 40 for 5GHz receives 2p respectively.

Channel 1 is the best for 2.4GHz and both channel 36 and 40 will be compared to channel 1 and BT in next comparison. Now it will compare between 2.4GHz, 5GHz and BT. The point distribution here is now channel 1=2p, channel 36=2p, channel 40=0p and BT=0p.

Because channel 1 and 36 has the same point and there is no preferred parameter set, the application will recommend either 2.4GHz channel 1 or 5GHz channel 36 connection. If it

(27)

were the same case but throughput is set as a preferred parameter i.e 2 points instead of 1, the 5GHz channel 36 connection would be selected.

Table 1: Example of algorithm 1

Algorithm 2: Like algorithm 1 this is also based on a point system. Channels metrics is compared to predetermined maximum and minimum values which result in a percentage value. All the metrics percentage values is added to form their final points. Before a channel is given points it must first pass a limit test. These limits are minimum/maximum requirements on metrics which a channel must fulfill to get points. The maximum points attainable by a channel is 400 points, 100 points for each metric. The output from the algorithm is a list of values sorted from highest to lowest, meaning channels with the most points will be displayed at the top. Below in equation 1 and 2 are examples on how much points is gained by a throughput test result of 15Mbit/s.

Points = Throughput − ThroughputMin

ThroughputMax − ThroughputMin ∗ 100 (1)

Points = 15000000 − 0

20000000 − 0 ∗ 100 = 75 (2)

(28)

Algorithm 3: Metrics are ranked by the user from the most important to the least impor- tant. An instance would be 1: Latency, 2: Packet loss, 3: Signal Strength and 4: Throughput.

In case of equal results on latency, the algorithm proceeds to check the next metric and so on. If not all connections got equal result on one check, the remaining connections will be excluded from subsequent checks.

4.3.1 Selected algorithm

The selected algorithm is algorithm 2. Implementation of the algorithm is described in the next paragraph.

The algorithm first check which Connection objects should be removed from the list as specified by the user’s limit inputs. Using the compareTo method that’s part of the Parameter class, a connection is compared to a limit. If there are several parameters specified e.g. a throughput and latency limit, as long as one of the requirements is not reached, that specific Connection object will be removed from the list. This is done for all Connection objects.

The next step is to assign points for each Connection object depending on a scale set for each metric and the result of the measured metrics. Where equation 3 is used to valuate throughput and equation 4 to valuate RSSI, latency and packet loss.

MetricValue − MetricMinValue

MetricMaxValue − MetricMinValue ∗ 100 (3)

1 − MetricValue − MetricMinValue

MetricMaxValue − MetricMinValue ∗ 100 (4) The points are then summed up to form the final result. The scale for each metric are setup where the minimum and maximum for each one is based on what each metric can reach. For throughput it’s set to between 0 and 20 mega bits per second because of the radio module limitations. Latency is set between 1 and 200 ms. For signal strength it’s between -30 and -100 dBm as any lower value than -100 would probably results in no connection and -30 as the RSSI didn’t go higher during the tests. Packet loss is between 0 and 100%.

4.4 Application

The following sub chapter refers to the classes and objects which are seen in appendix D as an UML diagram. The application starts with opting the user to input different values as seen in figure 4. First the user is asked if a limit is wanted and if yes, it then proceed to ask for a value.

The class Measurement consist of two instances of Module that handle the Telnet communi- cation with the two AWBII. These two Module objects handles basic AT-commands that are used to e.g reboot or switching between WLAN and BT. Measurement object consist of a vector with Connection objects. These Connection objects defines a connection and contains

(29)

Figure 4: Example of user input

information regarding what type of connection it is i.e BT or WLAN and which channel.

It also stores values gained from measuring the metrics. After initial setup, the application assure that packets can be sent to both modules before the test.

The Measurement object use a measurement time received from the user input, divides it equally between all connections in three intervals and their respective metric tests. The application then checks if the current connection to be tested is configured correctly on the modules i.e BT or WLAN connections with the correct channel. During run time, the application tells what’s currently being tested. It also indicate which interval it’s currently in the test.

The application first measures packet loss and latency, then proceed with the throughput test and lastly the signal strength test. The FactorMeasurement class has the necessary AT-commands and parser to extract the signal strength information but also to assure that Modules settings are correct along with error handling for eventual module disconnections and timeouts.

When the test is done, the Measurement class return a vector of Connection objects to the Presenter class which pass it on to the PointSystem class for valuation. Finally the connections that didn’t pass the user specified limits are displayed as well as the ones that passed with their final score. These are displayed from the best to the worst according to the algorithm. The outputs in figure 5 are examples of the results from the application tested in a office environment with the distances 1, 6 and 12 meters respectively between the modules.

Here all channels that passed all limits are shown and each of the metrics measured. The total points for each channel are lower overall when comparing the results, meaning that with longer distance comes worse results. This can be seen in figure 6 where plot ’a’ shows how throughput changes for different connections over a distance and ’b’ how the total point changes for each connection over a distance. The plots where fitted from the results shown in figure 5 using Matlab.

The basic flow of the application is seen in appendix C. Here it’s divided into four parts, setup, measurement, algorithm and output. The application have to restart for a new test.

Setup refers to setting up most of the variables, interface and the module connection to ensure everything works before the actual measurement. Input from the user also happens at this point. After measurement it then proceeds to the algorithm that both remove unwanted

(30)

connections and assign points. The application then sort the connections list by the the amount of points received by the algorithm and then outputs the results.

(a) 1 meter (b) 6 meter (c) 12 meter

Figure 5: Different outputs from the application.

(31)

(a) Throughput plot

(b) Points plot

Figure 6: Two plots made with Matlab

(32)

4.5 AT-commands and Telnet

The web interface is used at first for testing out the different commands available for the AWBII and configure the modules so they can switch between WLAN and BT. The web interface is also used for assigning static IP-addresses. The string sent to the AWBII often starts with AT* and ends with an abbreviation and a question mark(?) or an equals sign(=).

In figure 7 are two AT-commands used to get the currently activated WLAN channel(?) and to switch channel(=). The channel switching only have to be done on the AP module. The number 48 specifies that it is WLAN channel 48. This number is then received using a parser in the application.

Figure 7: Two different AT-commands to set and get the current AP channel

For sending the actual AT-command, a Telnet terminal is set up between the PC and modules.

Using POCO C++ library, an instance of DialogSocket is used for Telnet functionality of sending and receiving information stored in a buffer. One line of text is received each time from the buffer. This buffer is empty after the message is either OK or FAIL. The buffer is emptied each time after sending an AT-command. Figure 8 is an example of how this is used to reboot the modules. The object terminal is the DialogSocket object. The String AT*AMREBOOT tells the module to restart. The reboot is necessary for switching between WLAN channels and to switch between WLAN and BT. The reboot is done in the correct order (remote one first and then AP) to maintain connectivity.

Figure 8: AT-command sent to the module and response parsed

(33)

4.6 Test

Most of the testing is done with the help of a debugger and step by step of the code. Variables are seen over during run time. The web interface for the modules are seen in figure 9 which is used to confirm settings. When changing WLAN channels a phone application is used to confirm that the correct channel is used. The LEDs on the modules itself is used for observing if data is being sent between the modules when it is supposed to. The LEDS are seen in figure 10. The BT LED stops blinking and stays blue when a connection is made with the other module. It starts blinking rapidly when data is being sent. Other tests are done by analyzing the application output.

Figure 9: Web interface of the AWBII

Figure 10: LEDs indication layout on the AWBII

(34)

The test specification is used in order to confirm the functionality of both the application and algorithm. The requirement and test specification can be seen in the appendix A and B.

The EMC chamber is used to confirm certain metric measurements but without access to a signal generator. In the EMC chamber the modules was set up approximately 2 meters between. Tests performed involved the metrics packet loss, throughput, latency and signal strength. Tests involving the EMC chamber can be found in the test specification B. The results can be seen in table 2 where interference is generated between two other devices constantly sending data to each other on channel 1. In the table it’s seen that throughput is affected drastically for channel 1 and less for the other channels and not at all for BT.

Table 2: EMC chamber test results. w/o (without) w/ (with)

(35)

Table 3 show the result of a test done with different packet sizes. It shows how latency and packet loss is affected when packet size grows. This test was done in an office area with unknown interference and with 2 meter between the modules.

Table 3: Packet size test

In table 4 is an additional test to confirm packet loss test with interference on overlapping channels. The interfering channel 11 overlaps channel 10 and vice versa. No packet loss is the results. The throughput is higher on channel 10 than on channel 11.

Table 4: Test on overlapping channels

(36)
(37)

5 Discussion

This chapter will discuss different parts of the project.

The overall project was successful except some part that didn’t work as good as we hoped for. This application shows a basic method on of how the selection between two different wireless technologies could be done. The application has room for improvements and these are brought up in this chapter.

5.1 Algorithm

Initially algorithm 1 was chosen but as time went on several changes were made, so it was decided to make another algorithm called algorithm 2 implementing those changes instead.

There are many differences between the two, mainly that there is no preferred parameter anymore and that channels gets points for all of its metrics and not only those who came out as the best. Requirements 15, 16, 17 and 18 (seen in appendix A) has been removed to accommodate this. First the idea was that the algorithm should chose which connection to use but that was a misunderstanding and instead it should only give recommendations to the user. This and as well as that algorithm 1 felt a bit unjust in terms of point distribution was the source to why the algorithm changed so much. Therefore the new algorithm gives points to all tested connections instead. The preferred parameter is no longer needed since giving all metrics extra points would just mean giving all WLAN channels and Bluetooth extra points which would be redundant.

One of our concerns was if the new algorithm would be fair among the different connections.

We were aware of that many of the connections would end up with similar points in the end and that BT will often end up the lowest on the list because of the BT throughput limitations. We also hoped that with increased distance, BT would be put up higher on the list because of its advantage with frequency hopping which results in less interference and packet loss. This is proved as seen in figure 5. Looking at the points on the 12 meter results, BT is much more closer to the WLAN variants, this could be because of none affected packet loss and an overall smaller decrease in throughput for BT than WLAN.

With more factors like connected nodes the algorithm could be more complex. Then it had to compare different nodes to the AP and maybe create some sort of relation. This would then lead to a more spread result which you could use to calculate normal distribution and compare the different connections.

5.2 Application

A process had been started to make a GUI and the design was almost done when it hit us that Visual studio uses C++/CLI when generating the code. Since the rest of our code was written in pure C++ there would be some compatibility issues. The choice was to either change the code that would cause the compatibility issues or since there was not much time

References

Related documents

The main findings reported in this thesis are (i) the personality trait extroversion has a U- shaped relationship with conformity propensity – low and high scores on this trait

This Master thesis aims at implementing and verifying the BLE radio and protocol standard in an existing simulator, with potentially evaluating key BLE features as well as

It offer a significant amount of convenience for the client as well as a difficult challenge for application to provide the corresponding encapsulation method for concrete

Detta innebär att hubben inte bör användas i system där stor mängd data skickas mellan användaren och enheter via hubben.. Paketstorlekens betydelse var framför allt att

This chapter discusses the methods considered to configure the Virtual Network function in EPC-in-a-box, a study to identify mandatory interfaces required for the

Det är viktigt att arbetsterapeuten visar respekt och förståelse för dessa kulturella olikheter för att undvika missförstånd som kan leda till att åtgärder misslyckas

I föreliggande studie adresseras därför behovet av ökad förståelse för detta genom att undersöka organisatoriska faktorer som påverkar enhetschefer inom

The main aim of each industry is to provide better products with higher quality, but what makes them successful, is the process of preparing a product. These processes must consume