EECS-194 sp08

 Lab 1 - Embedded Internet

University of California, Berkeley
David E. Culler
Jonathan Hui
Jan 28, 2008

This lab is designed to be interactive.  It is should be done in groups. 
After each section, there will be discussion, Q&A and elaboration ==>. DISCUSS
Within each section are links to background reading materials.

Table of Contents

Setup

Subversion (SVN)

This part of be determined.

EECS194 VM

A group should form around each machine in the lab.  Log on

Internetworking Basics

The Internet is comprised of collections of client applications that issue requests to services on servers which in term provide responses and the communication between these participants involves transfering packets across a potentially wide variety of links interconnected by routers.   The most common example today is, of course, your web browser client issuing http GET and POST requests to a web server.  The initial portion of the URL identifies the server and the port on which the service is running.  The remainder of the URL is essentially arguments to that service,  identifying the document of interest or input values for generation of dynamic content.  In this class we are going to introduce a new class of clients and servers which are embedded deeply in the physical world and we will utilize a new low power wireless link developed for such embedded devices, but it will all fit together as a natural extension of the distributed system we know as the Internet and the Web.  In this first lab, we will get acquainted with several of the basic concepts that stitch the internet together.  Some of this may be a (pragmatic) review of your networking class.  But it will certainly involve some new twists.

internet organization

 To bring sanity to this widely complex global organism, it is organized into layers forming the Internet Protocol suite.  There is a wide variety of applications and application protocols.  The complementation parts of a distributed application (or service) communicate with each other using a transport protocol (TCP or UDP) that operates on an end-to-end basis.   TCP provides a reliable byte stream while UDP offers simple datagrams.  The transport is built up best-effort packet delivery across one or more particular networks or links..  This "narrow-waist" is the IP layer (layer 3) which provides homogeneous naming and routing over a wide diversity of links with different physical layers, different media access control (MAC)  protocols, different frame formats, and different physical media.  The most common, of course, are ethernet (in its many variants), wifi (in its variants), and point-to-point connections.

IP layered architecture

There is a deep connection between networking and operating systems, since the protocols that make a network function are implemented within the operating system or upon the operating system of the various machines.  At the endpoints, ports are what associate services with the application process that provides the service.  The port number is essentially the address of the service on the particular host. For example, http is on port 80, whereas SSH is on port 22.  See this link for a relatively complete list of ports.

In addition to the familiar services over the familiar transports, IP includes a collection of low level capabilities, call the Internet Control Message Protocol (ICMP), which support IP, including discovery and formation of networks, error processing, etc.  The basic ICMP tool is ping, which tests the reachability of a particular IP address.

Generally, we think of IP addresses as identifying machines.  A machine as a  hostname (e.g., inst.eecs.berkeley.edu)  which is translated to a global IP address (e.g., 128.32.42.199) by a internet-wide service called DNS (domain name service).  In fact, a machine can be attached to several network links through interfaces. Each interface on a machine has an IP address.
It will show you the network configuration associated with each interface on that machine.  You should see the "Ethernet adapter Local Area Connection". 
IP networking routes packets based on their destination IP address.  Each packet is originated at a source, passes through zero or more routers, to eventually arrive at its destination.  Each of the hops along the way decides on which interface to send the packet out.  They don't know how to get all the way to the destination, just how to get one hop closer.  They make this decision based on a local routing table. 
DISCUSS

Virtualization

Since IP networks are inherently spread out over large spaces and involve priviledged operating systems functions, they are a bit at odds with the carefully controlled, high quality instruction laboratory facility.  We are going to solve both problems with a trick called virtualization. 

We are going to run a little IP network within your windows machine using a Virtual Machine provided by VMWare.  It runs a complete operating system within a user application process on your windows box.  However, it functions like a completely separate machine that can talk to your native machine over a virtual ethernet. One nice thing is that you will have root access to your virtual machine linux OS.  So, we can do some real networking in this not-so-real setting.

We have configured the VM so that it and the Virtual Ethernet adapter of the windows system both sit behind a virtual NAT (network address translation) box.
You may notice that NTP (network time protocol) fails when linux boots. If so, try sudo /etc/init.d/ntpd restart. The passwd is the same as your user passwd.
Looks like a Linux machine, doesn't it? 
Here is what is going on.  A "virtual ethernet" connects the windows native machine and the virtual linux machine.  Both are sitting behind a "virtual NAT" (Network Address Translation) much like the cable or DSL router/firewall/NAT that you have at home.  The "uplink" of the NAT is back through the windows machine, so it all lives behind a single real IP address.

Virtual network

The 192.168.116.00 virtual ethernet is a private network, in that it is not directly accessible from other parts of the internet.  That's why we can make up the addresses and they don't have to be unique.  Communication outside this network looks as if it came from the 128.32.40.198 "global" ip address.

Network Applications and Services

There are basically two kinds of network applications:  remote terminals and services.  Let's play a little with both.  The classic remote terminal is telnet.  Its more modern, more  secure version is SSH.  In either case, you are issuing commands directly to the remote operating system (through the shell) and just forwarding the terminal IO across the network.   This is very handy.  You can use it wihtin scripts.  You can try things out by hand.
This is how you move files over the (virtual) network between the windows and linux machines.  Just like a network, isn't it.
You could try to go the other way, but you'd probably find that the windows side is not running a remote shell service.

The more general case is services. In fact, your remote terminal is invoking the remote shell service.  Ping is communicating with the remote ICMP echo service implemented within the network stack.  Your browser comnunicates with the remote HTTP server (i.e., the web server on port 80).  Your file transfer client works in tandem with a file transfer service.

In fact, let's use telnet to connect to the HTTP port, issue the GET request to the server, and display the sequence of (HTML) characters that come back.

Here's another general purpose networking application - nc (netcat).  Some call it the swiss army knife of networking.  It pretty much just opens a tcp or udp socket to an ip address and port and transfers data.  For example, if on a machine with ip address XYZ you run  nc -l 7171 it will start listening on port 7171.  On another machine, such as your linux vm run  nc XYZ 7171. What you type in to nc will appear on the listening side.  It is a simple tool to get at low level networking without socket programming.  (We'll do some of too in just a little bit.)
DISCUSS

LoWPAN Link

We are going to use the (virtual) linux machine as an IP router that supports a new kind of  wireless link for embedded applications - LoWPAN - Low Power Wireless Personal Area Network).  First, let's understand a little bit about this new class of network embedded computing pletform.

Berkeley TelosB Mote

The physical LoWPAN interface is going to be provided by a Berkeley TelosB Mote, shown below. This was the sixth in the series of UCB motes.  These were done as open source hardware, so the details are on line and they are manufactured by numerous companies around the world.  We will be using the newest generation mote, called EPIC, throughout the course.  But today we'll use Telos.  Both Telos and EPIC use a CC2420 2.4 GHz IEEE 802.15.4 radio supported by a TI MSP430 micocontroller and flash.  Telos plugs directly into a USB port and has on-board support for a variety of environmental sensors.  The antenna is embedded directly in the PCB.

telosb mote

LoWPAN NIC

You have a Berkeley telos mote that contains IEEE 802.15.4 NIC firmware provided by Arch Rock.  It is the one with no battery pack attached.   This is a new link.  You are familiar with IEEE 802.3 (ethernet) and IEEE 802.11 (WiFi).  This interface is a new wireless communication standard, IEEE 802.15.4. It recently became an IP link using the 6LoWPAN adaptation.  We'll learn a lot more about this later.  Today, we'll get some experience with it.

With WiFi you configure your network link by setting the SSID, channel and the security key.  Optionally, you may set various other link level features.  Similarly, IEEE 802.15.4 support a number of channels.  In the 2.4 GHz spectrum these are 11 - 26.  In addition, a logical network shares a PANID and an AES128 key. 
In this tutorial each group will have a private LoWPAN subnet - 10.97.0.0. 
You can change this with SUDO by editiing /opt/rosetta/conf/rosetta.conf.  Then run sudo /opt/rosetta/init.d/lowpan restart.
  
Each group should have two other 15.4 mote devices with battery packs. Like typical embedded devices, these utilize the microcontroller and its ADCs, DACs, and peripherals for sensing and controlling various apparati.

These motes are currently unassociated.  They are not part of any PAN.  Note that they have a 64 bit EUID mac address printed on the label on the side.  To bring the node into your network run the following, except with the last few hex pairs replaced by the ones for you node.
Associate both of your motes.

Your LoWPAN is what we used to call a Class B network, with 16-bit prefix (which you configured) and a 16-bit interface identifier.  10.97.0.0 is your router NIC. 

Using http://localhost:7673 you can see the state of your LoPWAN network.  Click on the Neighbor Table to see the link quality of nodes that are within range of the NIC.  The DHCP Address Assignment tab should show you the IP address of your newly associated node.  Notice, they have an IPv6 address as well as a classic IPv4 address. The IPv6 address has a 64-bit IPv6 prefix and a 64-bit IPv6 interface identifier.  These big identifiers get squeezed down to just a few bits by the 6LoWPAN adaptation layer. 
IEEE 802.15.4 introduces a "short MAC address" that is 16 bits in length, in addition to the 64-bit EUID.  Obviously this is not globally unique, but is assigned to be unique over the PAN.

If the LoWPAN network extends beyond the range of a single radio hop. routing is used to communicate over multiple hops, just as in the rest of the internet.  You can see the routing table from the NIC gateway to the other nodes with the Routing Table tab.

Congratulations, you now have an embedded internet. It looks something like this.

lowpan network organization
In a real setting we would nto have any of this virtualization involved.  We'd have a collection of real machines and real routers tying together real networks.  For the lab settting, we've got a real LoWPAN network and have created the rest of it "in a box".  Later in the course, we'll use a more real setting.


DISCUSS

Simple IP network applications

The standard IP networking utilities can now be used to for the network embedded devices.  Let's do a little poking around.
Lets go ahead and open up a remote shell onto that little embedded device. 
This opens a TCP connection to the telnet service (TCP port  23) on the embedded device.  The prompt that you see is coming back from the node over this TCP socket.  type '?'.   It is quite a bit more limited than your typical shell. The other critical thing that embedded devices do is actuate, i.e., control things. 

DISCUSS

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.
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.  Search the web to find the meaning of  the FE80 prefix.
The ping response also give 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 NIC 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 network?  (Look at the Routing Table.)


DISCUSS


OS networking APIs - Implementing 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".
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.
Perhaps its time to get a little more serious about network programming.  Here's an example of a very simple TCP client that issues a request and prints the response. 

Packet Formats at each layer

Now lets see what is really going on under the covers.  We'll set up a packet sniffer watching your channel.  So the same experiment. 

Push-Based Services

The web is still in the process of standardizing event-driven or push based services, since command/response is so deep in http and other protocols.  We have RSS and many variants that open a conection and allow the remote end to "push" more and more onto the document.  In the embedded space, periodic reporting and unscheduled alarms are very common.  So push is a natural.

A "model push service" akin to echo is provided for you ine $APPS/Count.  This is a UDP based push service, so it is easiest to think of it as a client.  It uses a timer to keep track of time going by and count the ticks.  Each tick it sends a UDP packet to listener service on a particular port on a particular IP address.


DISCUSS

Embedded Server TinyOS Socket Programming

We'll walk you through the TinyOS code for the applications and give you a set of test problems to implement yourself.