IoT in 5 days

In the beginning of Internet, that started as a research network called ARPANET in early 1980’s,the first Internet Protocol was defined, was called IPv4 (Internet Protocol version 4). First only research centers and Universities were connected, but after the U.S. Department of Defense decided to use IP as network protocol much more funding and vendors make it to develop and be much more widely used, including vendors that implemented it. The next step was that ARPANET became Internet and get open to everybody that wanted to connect to it, including companies and public services. The exponential growth of Internet happened when HTML and web sites appeared and started to be used world-wide in the beginning of 1990’s. As a consequence there was a rapid reduction in the number of free IP addresses available under IPv4, which was never designed to scale to these levels.

In order to get more addresses, you need more bits, which means a longer IP address, which means a new architecture, which means changes to all of the routing and network software. After examining a number of proposals, the IETF settled on IPv6, recommended in January 1995 in RFC 1752, sometimes also referred to as the Next Generation Internet Protocol, or IPng. The IETF updated the IPv6 standard in 1998 with the current definition included in RFC 2460. By 2004, IPv6 was widely available from industry and supported by most new network equipment. Today IPv6 coexist with IPv4 in the Internet and the amount of IPv6 traffic is quickly growing as more and more ISPs and content providers have started to make IPv6 available.

As you can see the history of IP and Internet are almost the same, and because of this the growth of Internet has made IPv4 become insufficient for its needs, and has led to the need of a new version of IP, IPv6, that is clearly the future of Internet and the protocol to be used to interconnect devices to send and/or receive information. There are even some technologies that are being developed only with IPv6 in mind, a good example in the context of the IoT is 6LowPAN. From now on we will only center on IPv6. If you know something about IPv4, then you have half the way done, if not, don’t worry we will cover the main concepts briefly and gently.

We will cover the basics of IPv6, the minimum you need to know about the last version of the Internet Protocol to understand why it’s so useful for the IoT and how it’s related with other protocols like 6LowPAN covered later in this book. You need to have understood the concepts covered in the Networking Basics chapter, so you are familiar with bits, bytes, networking stack, network layer, packets, IP header, etc. You should understand that IPv6 is the equivalent to IPv4, it is a different and non-compatible protocol, with respect to IPv4. In the following figure we represent the layered model used in the Internet.

IPv6 will operate in the layer 3, also called network layer. The pieces of data handled by layer 3 are called packets. We will have hosts that could be a PC, laptop or a sensor board, sending and/or receiving data packets. Hosts will be the source or destination of the packets. Routers instead are in charge of packet forwarding, and are responsible of deciding to which other router send the packet it has received. Internet is composed of a lot of routers, interconnected between them, which receive data packets in one interface and send then as quick as possible using another interface towards another forwarding router. The first thing you have to know is how an IPv6 packet looks like:

By one side you have the basic IPv6 header with a fixed size of 40 bytes, followed by upper layer data and optionally by some extensions headers, we will talk about extension headers later. As you can see there are several fields in the packet header, but compared with IPv4 header there are some improvements:

The most important fields are the source and destination addresses. As you already know, every IP device has a unique IP address that identifies it in the Internet. Also this IP address is used by routers to take their forwarding decisions.

IPv6 header have 128 bits for each IPv6 address, this allows for 2¹²⁸ addresses (approximately 3.4×1038,i.e., 3.4 followed by 38 zeroes), compared with IPv4 that have 32 bits to encode the IPv4 address allowing for 232 addresses (4,294,967,296).

We have seen the basic IPv6 header, and we already mentioned the extensions headers. To keep the basic header simple and of a fixed size, additional features are added to IPv6 by means of extensions header.

There are several extensions headers defined, as you can see in the previous figure, and they have to follow the shown order. Extensions headers:

The use of 128 bits for addresses brings some benefits:

All IPv6 addresses could be classified into the following categories (these categories also exist for IPv4):

Before entering into more detail about IPv6 addresses and the types of unicast addresses, let’s see how does they look like and what are the notation rules. You need to have them clear because probably this will be the first problem you will find in practice when using IPv6, how to write an address.

Notation rules are:

Three first rules tell you the basis of IPv6 address notation. The first thing you should know is that hexadecimal notation is used, i.e., sixteen symbols between 0 and F. You will have eight groups of four hexadecimal symbols, each group separated by a colon ":". The last two rules are for address notation compression, we will see how they work with some examples.

Let’s see some examples:

1) If we represent all the address bits we have the preferred form, for example: 2001:0db8:4004:0010:0000:0000:6543:0ffd

2) If we use squared brackets around the address we have the literal form of the address: [2001:0db8:4004:0010:0000:0000:6543:0ffd]

3) If we apply the fourth rule, allowing compression within each group eliminating leftmost zeroes, we have: 2001:db8:4004:10:0:0:6543:ffd

4) If we apply the fifth rule, allowing compression of one or more consecutive groups of all zeroes using "::", we have: 2001:db8:4004:10::6543:ffd

Last but not least you have to understand the concept of a network prefix, that indicates some fixed bits and some non-defined bits that could be used to create new sub-prefixes or to define complete IPv6 addresses.

Let’s see some examples:

1) The network prefix 2001:db8:1::/48 (the compressed form of 2001:0db8:0001:0000:0000:0000:0000:0000) indicates that the first 48 bits will allways be the same (2001:0db8:0001) but that we can play with the other 80 bits, for example, to obtain two smaller prefixes: 2001:db8:1:a::/64 and 2001:db8:1:b::/64.

2) If we take one of the smaller prefixes defined above, 2001:db8:1:b::/64, where the first 64 bits are fixed we have the rightmost 64 bits to assign, for example, to an IPv6 interface in a host: 2001:db8:1:b:1:2:3:4. This last example allow us to introduce a basic concept in IPv6: In a LAN (Local Area Network) always a /64 prefix is used. The rightmost 64 bits, are called the interface identifier (IID) because they identify uniquely a host’s interface in the local network defined by the /64 prefix. The following figure illustrates this statement:

Now you have seen your first IPv6 addresses we can enter into more detail about two types of addresses you will find when you start working with IPv6: reserved and unicast.

The following are some reserved or special purpose addresses:

The following are some types of unicast addresses:

As we have seen IPv6 has some features that makes it easier different things like global addressing and hosts address autoconfiguration. Because IPv6 provides as much addresses as we may need for some hundreds of years, we can put a global unicast IPv6 address on almost anything we may think of. This brings back the initial Internet paradigm that every IP device could communicate with every IP device. This end-to-end communication allow for bidirectional communication all over the Internet and between any IP device, what could result in collaborative applications and new ways of storing, sending and accessing the information. In the context of this book we can, for example, think on IPv6 sensors all around the world collecting, sending and being accessed from different places to create a world-wide mesh of physical values measured, stored and processed.

The availability of a huge amount of addresses have allowed a new mechanism called stateless address autoconfiguration (SLAAC) that didn’t exist with IPv4. Following is a brief summary of the ways you can configure an address on an IPv6 interface:

The advantage of SLAAC is that it simplifies the configuration of "dumb" devices, like sensors, cameras or any other device with low processing power. You don’t need to use any interface in the IP device to configure anything, just "plug and net". It also simplifies the network infrastructure needed to build a basic IPv6 network, because you don’t need additional device/server, you use the same router you need to send packets outside your network to configure the IP devices. We are not going to enter into details, but you just need to know that in a local network, usually called a LAN (Local Area Network), that is connected to a router, this router is in charge of sending all the information needed to the hosts using a RA (Router Advertisement) message. The router will send RAs periodically, but in order to make things happen quicker hosts can send a RS (Router Solicitation) message when its interface gets connected to the network. The router will send a RA immediately in response to the RS. The following figure show the packet exchange between a host that is just connected to a local network and some IPv6 destination in Internet:

1) R1 is the router that gives connectivity to host’s network nad is sending RAs periodically.

2) Both R1 and Host have a link-local address in their interfaces connected to the host’s LAN, this address is configured automatically when the interface is ready. Our host creates it’s link-local address by combining 64 leftmost bits of the link-local’s prefix (fe80::/64) and the rightmost 64 bits of a locally generated IID (:3432:7ff1:c001:c2a1). These link-local addresses could be used in the LAN to exchange packets, but not to send packets outside the LAN.

3) The hosts needs to basic things to be able to send packets to other networks: a global IPv6 address and the address of a gateway, i.e., a router to which send the packets it wants to get routed outside its network.

4) Although R1 is sending RAs periodically (usually each several seconds) when the host get connected and has configured its link-local address, it sends a RS to which R1 responds immediately with a RA containing two things: 4.1) A global prefix of length 64 that is intended for SLAAC. The host takes the received prefix and add to it a locally generated IID, usually the same as the one used for link-local address. This way a global IPv6 address is configured in the host and now can communicate with the IPv6 Internet 4.2) Implicitly included is the link-local address of R1, because is the source address of the RA. Our host could use this address to configure the default gateway, the place to which send the packets by default, for example, to reach an IPv6 host somewhere in Internet.

5) Once both the gateway and global IPv6 address are configured, the host can receive or send information. In the figure it has something to send (Tx Data) to a host in Internet, so it creates an IPv6 packet with IPv6 destination address the one of the destination host and source address it’s recently autoconfigured global address, and sends it to its gateway, R1’s link-local address. The destination host could answer with some data (Rx Data).

Following we will show how a simple IPv6 network will look like, including IPv6 addresses for all the networking devices.

We have four hosts, or sensors, or whatever IP device you have, and we want to put two of them in two different places, for example two floors in a building. We have just put four IP devices but you can have up to 264 (18,446,744,073,709,551,616) devices connected on the same LAN.

We create two LANs with a router on each one, both routers connected to a central router (R1) that provides connectivity to Internet. LAN1 is served by R2 (with link-local address fe80::2c:f3f4:1214:a on that LAN) and uses the prefix 2001:db8:1:2::/64 announced by SLAAC. LAN2 is served by R3 (with link-local address fe80::1b:fff4:3344:b on that LAN) and uses the prefix 2001:db8:1:3::/64 announced by SLAAC.

All hosts have both a link-local IPv6 address and a global IPv6 address autoconfigured using the announced prefix by the corresponding router by means of RAs. In addition, remember that each host also configure the gateway using the link-local address used by the router for the RA. Link-local address could be used for communication between hosts inside a LAN, but for communicating with hosts in other LAN or any other network outside its own LAN a global IPv6 address is needed.

On Win and Linux: https://my.vmware.com/web/vmware/free#desktop_end_user_computing/vmware_player/6_0

On OSX you can download VMWare Fusion: http://www.vmware.com/products/fusion

Instant Contiki is an entire Contiki development environment in a single download. It is an Ubuntu Linux virtual machine that runs in VMWare player and has Contiki and all the development tools, compilers, and simulators used in Contiki development installed. http://www.contiki-os.org/start.html

In VM, use 32 bit version, Instant_Contiki_Ubuntu_12.04_32-bit.vmdk Start Instant Contiki by running InstantContiki2.7.vmx. Wait for the virtual Ubuntu Linux boot up. Log into Instant Contiki. The password and user name is user. Don’t upgrade right now.

To update our code to the latest available contiki code, open a terminal and write:

ADD GIT FOR EXAMPLES

Open a terminal and write:

Check if you have version 4.7. If not, download the latest toolchain version here: http://sourceforge.net/projects/zolertia/files/Toolchain/

Open a terminal and write:

so it know that when you compile you do so for the z1 mote. You need to do this only once per application.

it starts compiling (ignore the warnings)

Connect the mote via USB.

In VM player: Player → Removable Devices → Signal Integrated Zolertia Z1 → Connect

In VMWare Fusion: Devices → USB Devices → Silicon Labs Zolertia Z1

Open a terminal and write:

Save the reference ID for next lab sessions (Z1RC0336). Each mote has a unique reference number. The port name is useful for programming and debugging.

Upload the preloaded Hello World application to the Z1 mote

Open a terminal and write:

if you don’t use the MOTE part, the system will install on the first device it finds. It is OK if you only have one device.

If you get this error:

you need to add yourself to the dialout group of Linux. You do it this way:

enter the root password, which is user

password is user.

open terminal and go again to /contiki/examples/hello-world and enter again

the first command resets the mote and the second one connects to the serial port and displays the result on the screen

Sceenshot missing

Note that the node ID is displayed.

Let’s see the main components of the Hello World example. View the code with:

When starting Contiki, you declare processes with a name. In each code you can have more processes. You declare the process like this:

The next step is adding a LED and the user button. Add picture.

Let’s create a new file. Go to: /home/user/contiki/examples/z1 with

Let’s name the new file test_led.c with

You have to add the dev/leds.h which is the library to manage the LED lights. To check the definition go to /home/user/contiki/core/dev.

Available LEDs commands:

Now try to turn ON only the red LED and see what happens

We now need to add the project to the makefile. So edit Makefile and make sure you have:

Now let’s compile and upload the new project with:

the make clean is used to erase previously compiled objects. Now the LED is red!

Missing pictures.

You can use prinf to visualize on the console what is happening in your application. It is really useful to debug your code, as you can print values of variables. Let’s try to print the status of the LED, using the unsigned char leds_get(void); function that is available in the documented functions (see above). Get the LED status and print its status on the screen.

If one LED is on, you will get the LED number (LEDs are numbered 1,2 and 4).

We now want to detect if the user button (see picture) has been pushed.

Create a new file in /home/user/contiki/examples/z1 called test_button.c The button in Contiki is considered as a sensor. We are going to use the dev/button-sensor.h library. It is a good process to give the process a meaningful name so it reflects what the process is about. Here is the code to print the button status:

Let’s modify the Makefile to add the new file.

You can leave the previously created test_led in the makefile. This process has an infinite loop (given by the wait()) to wait for the button the be pressed. The two conditions have to be met (event from a sensor and that event is the button being pressed) As soon as you press the button, you get the string printed.

Create a new file in /home/user/contiki/examples/z1 called test_timer.c. You don’t need any new library as the timer is part of Contiki’s core. We create a timer structure and we set the timer to expire after a given number of seconds. Then when the timer is expired we execute the code and restart the timer. This is the basic type of timer. Contiki has three types of timers.

There is one analog sensor in the Z1, and it provides the battery level expressed in milliVolts. There is an example in the Contiki example folder called test-battery.c. The example includes the battery level driver (battery-sensor.h). It activates the sensor and prints as fast as possible (with no delay) the battery level. When working with the ADC you need to convert the ADC integers in milliVolts. This is done with the following formula:

We are powering the Z1 with 5 Volts (this is why we multiply by 5). We divide the raw value by 4096 as it is a 1 shifted to 12 positions on the left (as the precision of the ADC is 12 bits). The internal power of the Z1 is 3V. There is an internal voltage divider that converts from 5V to 3.3V. If you connect the Z1 to the USB port, you will always get the highest value (around 3V). Two value are printed by the code in two columns: the raw value from the ADC and the converted value in milliVolts.

We can connect an external analog sensor. As an example, let’s connect the precision light sensor. It is important to know the voltage required by each sensor. If the sensor can be powered at 3V, it should be connected to the phidgets connector in the top row. If the sensor is powered at 5V it can be safely connected to the phidgets bottom row. Only if the mote is powered by USB, then you can use the 5V sensor. Insert phidgets Insert picture. If you use the phidgets cable, there is a single way to connect the node. Insert datasheet of the light sensors.

You need to convert the values coming from a 5V sensors as there is an internal voltage divider.

There is an example called test-phidgets.c. This will read values from an analog sensor and print them to the terminal. Connect the light sensor to the 3 V phidget connector. As this is an official example, there is no need to add it to the Makefile (it is already there!). Let’s compile the example code:

and connect to the node:

This is the result:

The light sensor is connected to Phidget 3V 2, so the raw value is 2202. Try to illuminate the sensor with a flashlight (from your mobile phone, for example) and then to keep it in your hand so that no light can reach it. http://www.phidgets.com/products.php?product_id=1127_0

Sensor Properties Sensor Type Light Sensor Output Type Non-Ratiometric Response Time Max 20 ms Measurement Error Max ± 5 % Peak Sensitivity Wavelength 580 nm Light Level Min 1 lx Light Level Max (3.3V) 660 lx Light Level Max (5V) 1 klx

As you can see, the light sensor can be connected to both the 5 V and 3.3 V phidget connector. The max measurable value changes depending where you connect it. The formula to translate SensorValue into luminosity is: Luminosity(lux)=SensorValue

The Z1 has an internal digital sensor: the 3 axis accelerometer. There is an example called test-adxl345.c. You don’t need to add it to the Makefile. Once uploaded, this is the result:

The accelerometer can give data in x,y and z axis and has three types of interrupts: when you do a single tap, when you do a double tap and when you let the sensor free-fall (pay attention not to damage the mote!). Try tapping once and twice. The code has two threads, one for the interruptions and the other for the LEDs. When Contiki starts, it triggers both the processes. The led_process thread triggers a timer that waits before turning off the LEDs. This is mostly done to filter the rapid signal coming from the accelerometer. The other process is the acceleration one. It assigns the callback for the led_off event. Interrupts can happen at any given time, are non periodic and totally asynchronous. They can be triggered by external sources (sensors, interrupt pins, etc) and should be cleared as soon as possible. When an interrupts happens, the interrupt handler (which is a process that checks the interrupt registers to find out which is the interrupt source) manages it and forwards it to the subscribed callback. In this example, I first start the accelerometer and then map the interrupts from the accelerometer to a specific callback function. Interrupt source 1 is mapped to the free fall callback handler and the tap interrupts are mapped to the interrupt source 2.

We then need to enable the interrupts like this:

What happens in the while cycle is that we read the values from each axis every second. If there are no interrupts, this will be the only thing shown in the terminal.

The ZIG001-mini is a digital temperature sensor. The advantage of using digital sensors is that you don’t have to do calibration of your own as they come factory-calibrated. They usually have a low power current consumption compared to their analog peers. They allow a more extended set of commands (turn on, turn off, configure interrupts). If you have a digital light sensor, you can set a threshold value when the sensor sends an interrupt, without the need for continuous polling. The example is available as test-sht11.c. The light digital sensor is also given as example in the same folder.

This example uses Wireshark to capture or examine a packet trace. A packet trace is a record of traffic at some location on the network, as if a snapshot was taken of all the bits that passed across a particular wire. The packet trace records a timestamp for each packet, along with the bits that make up the packet, from the low-layer headers to the higher-layer contents. Wireshark runs on most operating systems, including Windows, Mac and Linux. It provides a graphical UI that shows the sequence of packets and the meaning of the bits when interpreted as protocol headers and data. The packets are color-coded to convey their meaning, and Wireshark includes various ways to filter and analyze them to let you investigate different aspects of behavior. It is widely used to troubleshoot networks.

A common usage scenario is when a person wants to troubleshoot network problems or look at the internal workings of a network protocol. An important feature of Wireshark is the ability to capture and display a live stream of packets sent through the network. A user could, for example, see exactly what happens when he opens up a website or set up a wireless sensor network. t is also possible to filter and search on given packet attributes, which facilitates the debugging process.

When you open Wireshark, there’s a couple of toolbars at the top, an area called Filter, and a few boxes below in the main window. Online directly links you to Wiresharks site, a handy user guide, and information on the security of Wireshark. Under Files, you’ll find Open, which lets you open previously saved captures, and Sample Captures. You can download any of the sample captures through this website, and study the data. This will help you understand what kind of packets Wireshark can capture.

Lastly is the Capture section. This will let you choose your Interface. You can see each of the interfaces that are available. It’ll also show you which ones are active. Clicking details will show you some pretty generic information about that interface.

Under Start, you can choose one or more interfaces to check out. Capture Options allows you to customize what information you see during a capture. Take a look at your Capture Options – under here you can choose a filter, a capture file, and more. Under Capture Help, you can read up on how to capture, and you can check info on Network Media about what interfaces work on what platforms.

Let’s select an interface and click Start. To stop a capture, press the red square in the top toolbar. If you want to start a new capture, hit the green triangle which looks like a shark fin next to it. Now that you have got a finished capture, you can click File, and save, open, or merge the capture. You can print it, you can quit the program, and you can export your packet capture in a variety of ways.

Under edit, you can find a certain packet, with the search options, you can copy packets, you can mark (highlight) any specific packet, or all the packets. Another interesting thing you can do under Edit, is resetting the time value. You’ll notice that the time is in seconds incrementing. You can reset it from the packet you’ve clicked on. You can add a comment to a packet, configure profiles and preferences.

A packet sniffer is a must-have tool for any wireless network application, a sniffer allows to actually see what are you transmitting over the air, verifying both the transmissions are taking place, the frames/packets are properly formatted, and the communication is being done on a given channel.

There are commercial options available, such as the Texas Instruments SmartRF packet Sniffer (http://www.ti.com/tool/packet-sniffer), which can be executed using a CC2531 USB dongle (http://www.ti.com/tool/CC2531EMK) and allows capturing outgoing packets like the one below.

A preferred option is to use the SenSniff application (https://github.com/g-oikonomou/sensniff) paired with a Z1 mote and Wireshark (https://www.wireshark.org), already installed in instant Contiki.

To program the Z1 mote as a packet Sniffer go to the following location:

In the project-conf.h select the channel to sniff, by changing the RF_CHANNEL and CC2420_CONF_CHANNEL definitions. At the moment of writing this tutorial changing channels from the Sensniff application was not implemented but proposed as a feature, check the Sensniff’s README.md for changes and current status.

Compile and program:

Do not open a login session because the sniffer application uses the serial port to send its findings to the sensniff python script. Open a new terminal, and clone the sensniff project in your home folder:

And launch the sensniff application with the following command:

Sensniff will read data from the mote over the serial port, dissect the frames and pipe to /tmp/sensniff by default, now we need to connect the other extreme of the pipe to wireshark, else you will get the following warning:

Which is not severe, only means the other pipe endpoint is not connected. You can also save the sniffed frames to open later with wireshark, adding the following argument to the above command -p name.pcap, which will save the session output in a name.pcap file. Change the naming and location in where to store the file accordingly.

Open another terminal and launch wireshark with the following command, which will add the pipe as a capture interface:

Select the /tmp/sensniff interface from the droplist and click Start just above.

Be sure the pipe is configured to capture packets in promiscuous mode, alternatively you can increase the buffer size, but 1Mb is sufficient enough.

And the captured frames should start to appear on screen.

You can add specific filters to limit the frames being shown on screen, for this example make click at the Expression button and a list of available attributes per protocol are listed, scroll down until the IEEE 802.15.4 and check the available filters. You can also chain different filter arguments using the Filter box, in this case we only wanted to check the frames belonging to the PAN 0xABCD and coming from node c1:0c::0309, so we used the wpan.dst_pan and wpan.src64 attributes.

When closing the Sensniff python application, a session information is provided reporting the statistics:

Another must-to-have tool for analyzing and debugging 6loWPAN/IPv6 networks is Foren6 (http://cetic.github.io/foren6/), It uses a passive sniffer devices to reconstruct a visual and textual representation of network information, with a friendly graphical user interface and customizable layout, and allows amongst others to rewind the packet capture history and replay a previous packet trace.

To install follow the instructions at http://cetic.github.io/foren6/install.html

Then to program a Z1 mote as sniffer:

Then to connect to Foren6,

MISSING

The IEEE 802.15.4 standard is intended to conform to established radio frequency regulations and defines specific physical (PHY) layers according to country regulations, for example the 2.4-GHz and 868/915-MHz band PHY layers.

The Z1 motes operate on the unlicensed and worldwide available 2.4GHz band, The transmit scheme used is Direct Sequence Spread Spectrum (DSSS) modulation technique, up to 250Kbps data rate, allowing a wireless range of 50-100 mts.

A total of 16 channels are available in the 2.4-GHz band, numbered 11 to 26, each with a bandwidth of 2 MHz and a channel separation of 5 MHz. As other protocols also share this band, such as WiFi IEEE 802.11 and Bluetooth IEEE 802.15, we should be aware of using channels that are not interfered by other devices..

As shown above the channels 15, 20, 25 and 26 are not overlapping WiFi used channels, so typically most IEEE 802.15.4 based devices tend to operate on this frequencies. One handy tool to have is a spectrum analyser to scope the wireless medium, which shows the wireless activity on a given band. A spectrum analyzer will show you the received power at a certain frequency, so you will not know if the power comes from another node, a WiFi device or even a microwave oven! We can use the Z1 mote as a simple spectrum analyser, which sweeps across the list of supported channels and shows its radiated power.

To install the spectrum analyser application to the Z1 mote go to the following directory:

And compile, upload and execute the Java application to visualize the radiated power across channels:

The result are shown below.

You can change the default 26 radio channel in Contiki by changing or redefining the following defines: RF_CHANNEL

But, where are this constants declared? Let’s use a handy command line utility that allows to search for files and content within files, most useful when you need to find a declaration, definition, a file in which an error/warning message is printed, etc. To find where this definition is used by the Z1 platform use this command:

Which gives the following result:

Basically grep as used above uses the following arguments: -lr instructs the utility to search recursively through the directories for the required content between the quotes, from our current location (noted by the dot at the end of the command) transversing the directories structure.

The platform/z1/Contiki-conf.h shows the following information regarding the RF_CHANNEL

So we could either change the channel value directly to this file, but this change would affect other applications that perhaps need to operate on a given channel, so we could just override the RF_CHANNEL instead by adding the following to our applications Makefile:

Or at compilation time adding the following argument:

The PAN ID is an unique Personal Area Network identifier that namely distinguish our network from others in the same channel, thus allowing to subdivide a given channel into sub-networks, each having its own network traffic. By default in Contiki and for the Z1 mote the PAN ID is defined as`0xABCD`.

Link Estimation is an integral part of reliable communication in wireless networks. Various link estimation metrics have been proposed to effectively measure the quality of wireless links.

The ETX metric, or expected transmission count, is a measure of the quality of a path between two nodes in a wireless packet data network. ETX is the number of expected transmissions of a packet necessary for it to be received without error at its destination. This number varies from one to infinity. An ETX of one indicates a perfect transmission medium, where an ETX of infinity represents a completely non-functional link. Note that ETX is an expected transmission count for a future event, as opposed to an actual count of a past event. It is hence a real number, and not an integer.

ETX can be used as the routing metric. Routes with a lower metric are preferred. In a route that includes multiple hops, the metric is the sum of the ETX of the individual hops.

LQI (Link Quality Indicator) is a digital value often provide by Chipset vendors, which is an indicator of how well a signal is demodulated, or the strength and quality of the received packet, thus indicating a good or bad wireless medium. The CC2420 radio frequency transceiver used by the Z1 mote typically ranges from 110 (indicates a maximum quality frame) to 50 (typically the lowest quality frames detectable by the transceiver). The example below shows how the Packet Reception Rate decreases as the CC2420 LQI decreases.

RSSI is a generic radio receiver technology metric, used internally in a wireless networking device to determine when the amount of radio energy in the channel is below a certain threshold at which point the medium is clear to transmit. The end-user will likely observe a RSSI value when measuring the signal strength of a wireless network through the use of a wireless network monitoring tool like Wireshark, Kismet or Inssider.

There is no standardized relationship of any particular physical parameter to the RSSI reading, Vendors and chipset makers provide their own accuracy, granularity, and range for the actual power (measured as mW or dBm) and their range of RSSI values (from 0 to RSSI_Max), in the case of the CC2420 radio frequency transceiver on the Z1 mote, the RSSI can range from 0 to -100dBm, values close to 0 are related to good links and values close to -100 are closely related to a bad link, due to multiple factors such as distance, environmental, obstacles, interferences, etc. The image below shows how the Packet Reception Rate (PRR) dramatically decreases as the CC2420 RSSI values are worse.

To print the current channel, RSSI and LQI of the last received packet (thus the link attributes of the link between the node and the sender), we are going to revisit the unicast-receiver.c example, open the file and let’s include the following:

And add the following print statement in the receiver block. The external variables cc2420_last_rssi and cc2420_last_correlation (LQI) are updated on a new incoming packet, so it should match our received packet.

We should see something like the following:

ADD PICTURES

Click the File menu and click New simulation. Cooja now opens up the Create new simulation dialog. In this dialog, we may choose to give our simulation a new name, but for this example, we’ll just stick with My simulation. Leave the other options set as default. Click the Create button.

Cooja brings up the new simulation. You can choose what you want to visualize by using the Tools menu. The Network window shows all the motes in the simulated network - it is empty now, since we have no motes in our simulation. The Timeline window shows all communication events in the simulation over time - very handy for understanding what goes on in the network. The Mote output window shows all serial port printouts from all the motes. The Notes window is where we can put notes for our simulation. And the Simulation control window is where we start, pause, and reload our simulation.

Before we can simulate our network, we must add one or more motes. We do this via the Motes menu, where we click on Add motes. Since this is the first mote we add, we must first create a mote type to add. Click Create new mote type and select one of the available mote types. For this example, we click Z1 mote. to create an emulated Z1 mote type. Cooja opens the Create Mote Type dialog, in which we can choose a name for our mote type as well as the Contiki application that our mote type will run. For this example, we stick with the suggested name, and instead click on the Browse button on the right hand side to choose our Contiki application.

Setting up large networks on physical nodes can pose a challenge in terms of instrumenting properly to measure all network elements and having enough equipment available, that’s where Cooja comes handy.

Create a new simulation and define a new Z1 mote-based type of mote called Broadcast, do so by clicking on Motes, Add Motes, Create new mote type and select the Z1 mote. Use the example at examples/ipv6/simple-udp-rpl/broadcast-example.c

Press Compile and wait for the compilation to end, if there are no errors press Create and it will take you to the next screen. Now add 10 motes using Random positioning. Next in the Network Panel, click on View and add the following: Radio Environment, Mote ID and addresses. Now if you click on a Mote, it will display the Effective Radio coverage (green zone) and interference zone (grey zone) according to the selected medium model.

Be sure to also have the Network, Mote Output and Radio Messages panels in your layout, available at the Tools menu.

You now should be able to see the network traffic, the messages and the Motes console output, You can pause and start again the simulation to inspect the generated information at your own pace.

HOW CAN I LINK THE SECTION BEFORE TO THIS NEW SECTION?

RPL is IPv6 routing protocol for low power and lossy networks designed by IETF routing over low power and lossy network (ROLL) group [X], used as the defacto routing protocol in Contiki. RPL is a proactive distance vector protocol, it starts finding the routes as soon as the RPL network is initialized.

Image source: http://www.slideshare.net/asobimat/rpl-dodag

It supports three traffic patterns: MP2P, point-to-multipoint (P2MP) and point-to-point (P2P).

RPL builds a Destination Oriented DAGs (DODAGs) rooted towards one sink (DAG ROOT) identified by a unique identifier DODAGID. The DODAGs are optimized using a Objective Function (OF) metric identified by an Objective Code Point (OCP), which indicates the dynamic constraints and the metrics such as hop count, latency, expected transmission count, parents selection, energy, etc. A rank number is assigned to each node which can be used to determine its relative position and distance to the root in the DODAG.

Within a given network, there may be multiple, logically independent RPL instances. A RPL node may belong to multiple RPL instances, and may act as a router in some and as a leaf in others. A set of multiple DODAGs can be in a RPL INSTANCE and a node can be a member of multiple RPL INSTANCEs, but can belong to at most one DODAG per DAG INSTANCE.

A trickle timer mechanism [X] regulates DODAG Information Object (DIO) message transmissions, which are used to build and maintain upwards routes of the DODAG, advertising its RPL instance, DODAG ID, RANK and DODAG version number.

A node can request DODAG information by sending DODAG Information Solicitation messages (DIS), soliciting DIO messages from its neighborhoods to update its routing information and join an instance.

Nodes have to monitor DIO messages before joining a DODAG, and then join a DODAG by selecting a parent Node from its neighbors using its advertised latency, OF and RANK. Destination Advertisement Object (DAO) messages are used to maintain downward routes by selecting the preferred parent with lower rank and sending a packet to the DAG ROOT through each of the intermediate Nodes.

PLACE IMAGE SHOWING RPL MESSAGES HERE !!!

RPL has two mechanisms to repair the topology of the DODAG, one to to avoid looping and allow nodes to join/rejoin, and other called global repair [X]. Global repair is initiated at the DODAG ROOT by incrementing the DODAG Version Number to create a new DODAG Version.

The border router or edge router is typically a device sitting at the edge of our network which allow us to talk to outside networks, using its built-in network interfaces, such as WiFI, Ethernet, Serial, etc. In Contiki the current and most used border router application implements a serial-based interface called SLIP, it allows to connect a given mote to a host using scripts like tunslip6 (tools/tunslip6) over the serial port, creating a tunneled network interface, which can be given an IPv6 prefix to set the network global IPv6 addresses.

The most used border router application in Contiki is located at examples/ipv6/rpl-border-router. Motes running the border router application will typically send over the serial port a character sequence, to synchronize with the host over the tunslip6 script. Normally is preferable to configure the border router as a non-sleeping device, so the radio receiver is always on. You can configure the border router settings using the project-conf.h file.

By default the border-router applications includes a built-in web server, displaying information about the network, such as the immediate neighbors (1-hop located) and the known routes to nodes in its network. To enable the web server, the WITH_WEBSERVER flag should be enabled, and by default it will add the httpd-simple.c application.

To compile and upload the border router to the Mote just type:

And to connect the border router to your host run:

By default it will try to connect to a mote at port /dev/ttyUSB0 using the following serial settings: 115200 baudrate 8N1. If you do not specify an IPv6 prefix it will use the default aaaa::1/64, to specify a specific one run the tunslip tool instead using the following:

You can also compile and run the tunslip6 tool directly from the tools location, to compile just type:

And to run with specific arguments, if you are required to use a Z1 mote connected to a specific serial port, or require to name your tunnel connection with a specific naming, or proxify to a given address and port. Run ./tunslip -H for more information.

Open Cooja and load the file at examples/z1/ipv6/z1-websense/example-z1-websense.csc.

The first noticeable thing about the example is the topology at the Network panel, the Node 6 corresponds to the Border Router Mote, which has only 1 neighbor in its wireless coverage area, and downwards we can see the Border Router being 4-hops apart from the Mote 5. The example contain a step-by-step guide in the Notes panel for you to also follow.

Motes 1 to 5 have been programed with an example called z1-websense, which is a small built-in webserver displaying a history chart with the battery and temperature readings of the Mote, accessible from our web browsers.

Now enable the Border Router (from now on BR) to connect over the serial socket to our host, right-click the BR and select the Serial Socket (SERVER) option from the More tools panel. This will allow us to connect to the simulated BR via the tunslip6 script, run the tool by typing:

Or from the examples/ipv6/rpl-border-router location you can run instead:

You can replace the IPv6 prefix with your own, the output is shown below. The connection status is shown in the Serial Socket panel in your Cooja layout, it should have changed from listening to Connected.

Notice the tunnel connection has been created but no prefix has been given yet. At the Simulation control panel click Start, we should see the BR receiving the aaaa:: prefix by default, thus creating the global server IPv6 address, and it will start sending DIO messages to advertise itself, the Nodes 1-5 will send multicast DIS to request DAG information.

Finally Node 1 (in range of BR) will receive the BR DIO, add BR as preferred parent, joining the newly found instance, replying to BR with a DAO to advertise itself to the BR. Node 1 will multicast DIO messages, Node 2 will receive it, join the instance through Node 1, and reply with a DAO message, which will be used by Node 1 to add Node 2 to its routing table, then forward it upstream to BR.

You can pause the simulation and examine the packets and console output at your own pace, simply click the Pause button at the Simulation Control panel. When you are done click Restart. To check we have connectivity from our host to the simulated Motes, open a terminal console and try to ping the devices like follows:

Replace the prefix with your own.

Now open a web browser (Firefox in our example) and type in the URL panel the BR IPv6 public address as follows:

It will display the BR built-in webserver, showing the immediate neighbors and the known routes to the Motes in its instance. We can notice the next-hop neighbor to reach Motes 2 to 5 is Mote 1 as expected.

Now to access the webserver running on the nodes, type the global address of any of the Motes in the network. The battery and temperature reading diplayed are emulated values.

You can examine the packets being sent and received by going through the Radio Messages panel, click on the Analyzer menu and select the 6LoWPAN analyzer with PCAP to format the messages with PCAP to open later using wireshark, click on the File menu and Save To File.

Exercise: connect your simulation

In networking, a tunnelling protocol enables new networking functions while still preserving the underlying network as it is. IPv6 tunneling enables IPv6 hosts and routers to connect with other IPv6 hosts and routers over the existing IPv4 Internet. The main purpose of IPv6 tunneling is to deploy IPv6 as well as maintain compatibility with the existing base of IPv4 hosts and routers. IPv6 tunneling encapsulates IPv6 datagrams within IPv4 packets. The encapsulated packets travel across an IPv4 Internet until they reach their destination host or router. The IPv6-aware host or router decapsulates the IPv6 datagrams, forwarding them as needed.

Several tunnel brokers have been developed along with a Tunnel Setup Protocol (TSP). TSP allows IPv4 or IPv6 packets to be encapsulated and carried over IPv4, IPv6 or IPv4 NATs. TSP sets up the tunnel parameters between a user and a server. It handles authentication, encapsulation, IP address assignment and DNS functionality.

One of these TSP providers is gogo6, which provides the gogoCLIENT. The gogoCLIENT connected to the Freenet6 service provides IPv6 connectivity so you can test your v6 network, service or app.

To use the free gogo6 service, setup an account at http://www.gogo6.com/profile/gogoCLIENT

To set up the client on Ubuntu, first install the client with:

Modify the config file from /etc/gogoc/gogoc.conf with

Locate and modify the following lines:

Start the gogo client with

and you are ready to go.

Try a ping to ipv6.google.com with

If you can ping google via IPv6, you are ready to go!

You can use http://lg.as6453.net/bin/lg.cgi to check if your machine is visible from the Internet