You are on page 1of 6

Author: Ryan Hu

LAB 4: Wireless Network Performance and Analysis


Wireless network performance measurement is important where it can not only quantify the values of
performance metrics we care but also help identify a possible problem. For the already built networking
systems, it is usually not easy or recommended to put the diagnosis code to measure the performance.
Therefore, there are some tools doing network performance monitoring that can passively analyze the
network performance based on the over-the-air traffic. Although there are commercial tools on the
market, we need to do the performance measurement by ourselves in order to understand the basic
principles behind the scene.

In this lab, we are going to do some wireless network performance measurement and analysis based on
the 6LoWPAN networks (a low-power IPv6 network consisting of motes or small radio boards). As we
have introduced in the lecture in Week 5, wireless network performance measurement can be done at
different OSI layers. We are going to monitor the network traffic and figure out the throughput
performance at the transport layer. We are using the UDP (User Datagram Protocol) example we
previously worked on but we are going to do some performance measurement this time.

Specifically, we will measure the packet reception ratio (PRR) and throughput of the network at the
transport layer. To do this, we can use the approach such as capturing the packets over the air and do
the data analysis based on it. This option is possible for us as Cooja has the built-in Radio Message tool
which allows us to see the results and export them into Wireshark for further analysis. Here, we use
another approach where we analyze the throughput from the debug mote output. (Note in this way we
are flexible to write our codes in the mote software to generate custom mote outputs. If an actual
hardware platform is used, instead of checking the debug output from Mote Output window in Cooja,
we can check these outputs from the serial ports of the platform.)

It is worth noting that the throughput is generally defined as a measure of how much data transmitted
in a given amount of time. In this sense, you may see a slight different definition in an article sometimes
considering the meaning of the how much data transmitted and amount of time. However, based on
the performance metrics we covered in the lecture, the definition of throughput used in this lab is:

(Total data of packets received in bytes) / (Duration of this data transmission session)

In this case, the duration is calculated based on the time difference between when the first UDP packet
is sent and when the simulate ends. We will log the throughput every time when a packet is received
and represent it in a plot, so you can see how the throughput approaches to a stable state over time.
You will see how it is done in the test script given in this manual later.

PRR is straightforward to understand as it is defined as

(Total packets received at the receiver) / (the packets sent by receiver(s))

In our network, we have only one receiver which is Mote#1. Moreover, because the possible packet loss
could happen (mostly because UDP does not handle the flow/error control as TCP does), the value of
PRR should be less than or equal to 1.

Copyright 2017 Ryan Hu


ryan.hu@senecacollege.ca
Author: Ryan Hu

Now, lets follow the following steps to get started:

1 Open the original rpl-udp.csc simulation file in this directory


~/contiki/examples/ipv6/rpl-udp (note tilde sign means your home directory on
Ubuntu).
2 Once Cooja loads up the simulation, you should see the following simulation script editor
window:

Example

If this window is closed, you can enable it by clicking the top menu Tools->Simulation script
editor. Please do not open two windows like this as it will confuse you.

The simulation test script shown in the figure above is written in JavaScript (a script language
having similar Syntax as C while one major difference is its variables dont have to be declared
before use), where some essential APIs of the script provided by Cooja can be checked at
https://github.com/contiki-os/contiki/wiki/Using-Cooja-Test-Scripts-to-Automate-Simulations
for more info. (You dont have to check it now in order to finish the lab work.)

3 The default test script is okay to do some PRR measurement but we are going to make few
modifications in order to make it better fit our needs. For example, we will customize the result
output and add the scripts for calculating the throughput.
a. First, in the Simulation script editor window, uncheck Active in the Run menu as
shown in the figure below.

b. Now its time to modify the script as we want to shorten the simulation time and put
the two metrics in the test script and output the results. This will allow us to calculate
the throughput whenever the server receives a new packet. The complete script file is
attached at https://goo.gl/pX3osU and you can attach the contents to this window, or

Copyright 2017 Ryan Hu


ryan.hu@senecacollege.ca
Author: Ryan Hu

download this Cooja simulation file at https://goo.gl/qXuTUP which contains the script
(note it needs to be put in the same folder as rpl-udp.csc to make it work). You can
see the detailed comments I wrote for you to understand the meaning of the codes.
(The original test script with my comments can be downloaded at https://goo.gl/CLGHbp.)
c. Check Active in the Run menu again and reload the simulation. After it is reloaded,
you should be able to run the simulation with the test script.
4 Copy the output in the Simulation script editor *active* window as shown below (excluding the
last 4 lines) and save it into a text file for later data analysis.

Lab Questions (attached your results to the lab report):

(Mark distribution: Q1=50%, Q2=40%, Q3=10%)

1 Based on the text file you just saved, plot PRR and throughput values (not the final PRR and
throughput values displayed when the simulation times out) versus timestamps into two figures
with the tool you prefer such as Octave, R or Excel. Attach TWO plots here, and explain what
the performance plots suggest.

(If you want to use Excel, check the video tutorials at


https://www.youtube.com/watch?v=KTDahCZq0pk and
https://www.youtube.com/watch?v=Xn7Sd5Uu42A if you are not sure how to import data from
text file into Excel and how to plot data with Excel.)

2 With the same network setup we used, if the UDP client motes suffering some packet loss which
could be caused by mobility or congestion, do you expect the same throughput performance or
a different one? Why? In order to see how that will impact your network performance
quantitatively, please modify the TX/RX success ratio of Mote#27, Mote#20, Mote#5, Mote#14,

Copyright 2017 Ryan Hu


ryan.hu@senecacollege.ca
Author: Ryan Hu

Mote#23 from 100% to 50%. Plot your new results into the two figures (one for throughput and
the other for PRR) similar to Q1.

Hint: the following figures show how to change the TX/RX success ratio.

3 Without changing the network setup we used in this lab, if we would like to measure the IP
datagrams transmitted at the network layer, based on this lab manual, describe a method to do
so with detailed steps.

FAQs (you can check them after you finish the lab assignment):
There are some questions from students and I would like to address them here.

1. Why we use the examples in the Contiki OS distribution?

There are few reasons to do so: (1) the example covers essential functionality provided by
Contiki OS and share the familiar concepts of network programming. Thus, if we later work on
the device using a TCP/IP stack on Linux or other OS, we can easy pick up the knowledge we
gained from this course. (2) The labs are designed to be a smooth transition from one to
another. The UDP example can show how a wireless network works from data link layer,
network layer, and transport layer to the application layer. For wireless networks (e.g., LTE,

Copyright 2017 Ryan Hu


ryan.hu@senecacollege.ca
Author: Ryan Hu

WiMAX, WiFi, etc.) with different underlying PHY and DLC technologies than IEEE 802.15.4, the
example still captures some essential wireless networking concepts although they may have
different network setups. (3) We actually added new elements while keep the basic example
used.

2. I didnt know how to write the wireless network example by myself with C.

It is true that it is not a programming course but it is a course addressing C programming in the
wireless networking context based on many students interests but, most importantly, this can
also help us un-blackbox the wireless communication systems. Simply put, we dont have to
be C programmers to be successful in this course.

Excelling at C programming language itself needs different levels of efforts and it also needs a lot
of exercises by your own. (In general, learning programming by examples is an effective way to
develop your programming skills.) It is also true that many students only know C for the first
time so we need to do some lab work that everyone can work on. However, by the end of the
day, you will gain some skills beyond the language syntax level, such as reading the C codes,
using basic or 3rd-party C libraries like IP in Contiki OS, and strengthening the understanding of
C for some students who have known it. However, you are encouraged to do more for the
Project 2 if you are capable of doing so. You may find what you achieve in this course very useful
in the future.

It is fair to say if you learn the C programming language basics (such as the knowledge gained
from Lynda.com training videos) and fully understand the examples we have done (i.e., able to
describe which code snippet does what), you will be able to succeed in this course which will
lead to your further development of programming skills and professional work.

3. Where can I check the support documents of Contiki OS/Cooja?

As I mentioned in the previous lab, the best resource is Contiki WiKi at


https://github.com/contiki-os/contiki/wiki which lists various support documents. There are
many articles for Contiki OS on the net as well because of its popularity in the open-source
community; however, make sure the environment is the same. There are many research papers
talking about the implementation of Contiki OS functions which are worth reading if you want to
gain in-depth knowledge of network protocol implementation. In addition, as a rule of thumb, if
you cannot find the information you need from these resources, reading the source code of
Contiki OS is the best bet as many programmers always do, because the source code basically
explains everything in a programming language.

4. Do we have to use Cooja all the time? Whats the relationship between Cooja and Contiki OS?

The answer to the first question is yes or no. Cooja is the network simulator which can simulate
the near-real network environment with wireless devices running Contiki OS. This way you dont
have to buy any hardware or make efforts on setting up a real network before you know what
exactly the network (performance) will look like. You can consider a different hardware platform

Copyright 2017 Ryan Hu


ryan.hu@senecacollege.ca
Author: Ryan Hu

if you are not satisfied with the one you are simulating with Cooja. As I mentioned before,
Contiki OS supports multiple hardware platforms, and these are the options you may have.
However, you can create a custom hardware platform for your own with or without modifying
the Contiki source code because it is an open-source project. However, always doubly check the
open-source license if you want to commercialize your platform/work.

Copyright 2017 Ryan Hu


ryan.hu@senecacollege.ca