Wireless Embedded Internet Short Course

 Lab 2 - Embedded Internet

University of California, Berkeley
David E. Culler

This lab is designed to be interactive.  It is should be done in groups. 

Table of Contents


In Lab1 we extended our Internet to include embedded IEEE 802.15. devices using 6LoWPAN to provide IPv6 connectivity and we saw routers that tie LoWPAN networks with conventional ethernet and wifi networks.  You may notice that WiFi and ethernet are often bridged, rather than routed.  One of the important properties of the Internet architecture is that it allows network designed to organize their networks according to need.  Bridging connects two different links within the same subnet. i.e., it is a layer 2 relationship.  Routing connects distinct subnets, which may be the same or different media.  It is a layer 3 relationship.  Layer 4, transport, operates over IP regardless.  Bridging  offers less control over what hosts are able to talk to what other hosts and how, but it is also somewhat simpler as no routing configuration is required.  Bridging tends to be more common with similar media (e.g., ethernet and wifi) in a common adminstrative domain.

Now that we have a whole new class of Internet device, this lab will show how the internet looks from the embedded deivce's perspective.  We gain that perspective because we can log into a node and perform networking operations from there.

Embedded IPv6

Let's explore a little more of IPv6.

Connectivity Testing

Let's do a little more with the remote shell on the embedded mote.  This one should be done in small groups.
Multicast is a foundational concept in IPv6, rather than an add on as it is in IPv4.  The various link level facilities that we use to bring up IPv4 networks, like ARP, RARP, BOOTP, DHCP, are provided instead at the IP level in a link independent manner with multicast groups.  For example, FF02::1 is the "Link Local All Nodes" multicast group. 
You will see responses from all the other nodes in range of the mote issuing the ping.  This is the link local scope. 
Notice the source address of the responses.  Whihc nodes are these?
The ping response also gives the Receive Signal Strength Indicator (RSSI)  of the incoming packet.  These particular radios have a transmit power of  0 dBm or about 1 mw.  (WiFi is about 100 mW and so is your cell phone.)  They have a receive sensitivity about -92 dBm.

Now its time to do some connectivity testing with low power wireless networks embedded in physical space.  With one mote in reasonable proximity of the LBR you can move the other own to various places, distances, through walls, behind objects, in your pocket.  How does the connectivity vary?  Did you get to a multiple hop network?  (Look at the Routing Table.)


Clients and Servers

Network applications, including clients, servers, routers, proxies, and overlays, are implemented on the networking APIs made available by the operating systems on the particular machines.  In Unix the API is primarily BSD Sockets and on Windows WINSOCK.  These applications are also concurrency intensive, managing multiple connections, etc.  So the API is closely related to the OS concurrency model.  Embedded devices are mostly event driven, with collections of state machines responding to changes in their environment and taking actions, rather than long threads of sequential processing.  We will be using an event-driven, modular socket-like API in TinyOS.

We could build our embedded web service applications over the shell by scripting commands.  And this is indeed quite common.  Or we could implement services that are tailored to the usage that we have in mind.  On class of such services is a pull model where we issue requests to an embedded server and get responses - just like a web server.

Pull-based Services

The simplest of these is echo, so let's start by building and uploading a simple ECHO server onto one of your nodes "Over the Air".

For $TOS = the source tree provided for the lab.
You will see the pages of the image spooled out over the network.  This is an example of a selective acknowledgement scheme.  The code image is bigger than RAM, so it is broken into pages.  Still each page is many packets.  The software update protocol sends all the packets in a page and then collects the holes.  It then sends these selective entities. Once the entire page is confirmed in the node, it moves on.  You see the progress on the LEDs.
You will see a glowing sequence as the node reboots from the program image stored in its external flash.

The setting here in the lab is quite atypical of production operation, since many people are doing lots of updates.  SWUPDATE would more typically be used to roll out tested versions of the firmware to devices that are deployed in important points of interest.  The alternative available to us is to program motes directly over the USB link.  To do this, you must connect your  EPIC interface board to the USB connector.  Make sure that the VM owns the USB device (via devices>removable USB device).  Run motelist to confirm. 
Then run make epic reinstall.

 Now we should have TCP and UDP echo services running on port 7.  Let's try it out.  For the TCP services, we could use our old friend
To exercise the UDP services, we'll need NC
In order to permit inexpensive, low power implementations. IEEE 802.15.4 packets are very limtied in size.  The total MTU (media transfer unit) is 128 bytes.  Let's do a little experiment that will show the difference in the transport protocols: TCP and UDP.

Packet Formats at each layer

Now lets see what is really going on under the covers.  You've got a packet sniffer called Wireshark.  Look in the Applications>Internet.  This is a handy tool when developing  network algorithms.

We'll set up a packet sniffer watching your channel.  Do the same experiment. 

Simple Web Server

One important virtue of the layered IP architecture is that lots of different application protocols can run over the same networking and transport layers.  Once we have the embedded internet, it is natural to consider the embedded Web.  Let's put a really simple web server on your node. 

cd $TOS/simpleWeb and take a look at what you find there.  This is actually an oversimplification of the HTTP protocol.  Upon receiving any request on port 80, it responds with HTML.  We will develop a high quality HTTP server later.  Build this one with make epic.  Install it on you node.  Feel free to update the HTML contents to make it more interesting. 

Congratulations, you have built your first IP/USN embedded web device.

Push-Based Services

While the web is primarily pull oriented, in embedded instrumentation applications periodic reporting and unscheduled alarms are very common.  The devices push readings to controllers, loggers, analyzers and other infrastructural elements.
A "model push service" akin to echo is provided for you ine $TOS/report.  This is a UDP based push service.  We've kept it simple.  Not a lot of sensing yet.  The issue is where do the packets get pushed to?  We've built a special peer that you can find in $UNIX/ipv4/updreporter.  It will contact the mote, providing it with a "return IP address".  The mote report application pushes period readings to this address and udp port until it gets contacted by a new reporter.






One of the challenges with embedded network devices is that there is often no human user interface.  When you configure network access on your laptop or smart phone you do so from the phone.   It shows the available networks.  You select one, enter the passwd and so on.  There are many WiFi appliances, such as web cams.  Generally they have an ethernet interface for configuration.   The device gets an IP address over DHCP.  You discover this using BonJour or some special tool and open a browser to the device.  Then you can configure its WiFi interface.  Then you are up and running.  The networking aspects of this are a solved problem - DHCP.  The operational process of entering the security keys depends on the operational model of the organization.  It is very different rolling out an embedded networks of thousands of nodes on lamp poles and putting together a prototype in the lab.  At scale, the keys are transferred through an operational process.

Above, we have assume that your node is associated with a particular LoWPAN network.  If authentication and encryption are utilized, it possesses the appropriate keys. We have also provided a mechanism for that association to be established.  This is the kind of step that would typically be done in the a secure deployment process. 

A node can be placed in association mode by holding the user button while resetting it.  (Also, if the node is programmed by downloading it firmware directly over the USB, it will be placed in association mode.)  For a period of one minute, its three LEDs will flash in unison.  During this time, it will scan all the channels and accept association messages from a device in direct proximity. 

On the LOWPAN tab of the router hosting the network that you desire to associate with, under neighbors you will find an ASSOCIATE button.  This will allow nodes that are in association mode to associate with the LoWPAN network.

If you are using the router built in to the VM linux image, it is lacking the Association UI.  Instead, you can initiate the operation using the REST interface

    curl http://localhost:7673/api/V1/neighbors/ -d "action=associate&eui64=00-17-3B-00-0E-DA-90-C4"

Observe that this connecting to the router server interface on localhost and port number 7673.  The EUID64 is the 15.4 mac address of the node.  To associate all nodes that are in association mode, use the default.

  curl http://localhost:7673/api/V1/neighbors/ -d "action=associate&eui64=FF-FF-FF-FF-FF-FF-FF-FF"

USB reprogramming

You can also program nodes directly over USB.  The VM and the native Windows share the USB.  In a typical configuration, the USB device is accessible from the machine that was in focus when the device is inserted.  The VM has an option to attached or remove a USB device in the pull down commands on the top bar.  Verify that the mote is associated with the machine by running
It should respond with a description of the mote.

To compile and download an application for the epic platform, run
    make epic install

To download a previously compiled binary, run
    make epic reinstall

For the telosb platform, replace the platform name in the make command.