Wireless Embedded Internet Short Course

 Lab 1 - Internet Basics

University of California, Berkeley
David E. Culler


This lab is designed to be interactive.  It can 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.

[Instructor note.  This lab writeup assumes that motes are programmed with a Shell and associated with a LoWPAN network.  It describes a network organization with the Lab LAN forming the WAN of the LowPAN router.  Standalone variants could use the LAN interface to the LoWPAN router and skip the route configuration section.  Alternatively, a NATed VM running the LoWPAN router with a bridge node can be used.]

Table of Contents

Internetworking Basics

The Internet is comprised of collections of client applications that issue requests to services on servers, which in term provide responses. 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 http POST requests to a web server.  The initial portion of the URI in your browser bar identifies the server (by its hostname or IP address) and the port on which the service is running (by default  http port 80).  The remainder of the URI 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.  For many this will be a review.  But it will certainly involve some new twists.

internet organization

 To bring sanity to the widely complex global organism that is the Internet, it is organized into layers forming the Internet Protocol suite. 
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 each service with the application process that provides the service.  The port number is essentially the address (albeit a short 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 has 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.   An  IP address actually identifies a particular interface on a particular machine.
  This essentially give a view into the link layer at your host machine.  It shows you the network configuration associated with each interface on that machine.  You should see the "Ethernet adapter Local Area Connection" on windows or eth0 on linux.  We've configured the linux as a dual stack, so each interface has both an IPv4 address and an IPv6 address.
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.

VM player has two network configurations that it supports.

In NAT, the VM and the Virtual Ethernet adapter of the windows system both sit behind a virtual NAT (network address translation) box.

In Bridged, the native Windows machine and the virtual Linux machine are both clients on the network that the native machine attaches too.  The both get an IP address on that link for the DHCP server.
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.  Or you can set the it with sudo date -s "mon day year hr:min".
Looks like a Linux machine, doesn't it? 
Here is what is going on.  (In NAT mode it is more complicated.  See the NAT section below.)  Assuming that the ethernet that you are plugged into provides DHCP on a 192.168.116.0 subnet.  (The specific addresses will be different than what you see here, of course.)

Bridged VM

The 192.168.116.00 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 across the whole world.  They are only used inside out private portion of the Internet.  Communication outside this network looks as if it came from the 128.32.40.198 "global" ip address.  We can route within our network and we can route out (for example when we connect to a server), but there is no way for hosts on the outside to route in, unless internal hosts are exposed through the firewall.

Internet Control and Management Protocol (ICMP)

ICMP is and inherent part of the IP layer.  Most people are familiar with it through the ping tool that you used above.  IPv4 is built upon the concept of subnet as the basic adminstrative unit.  As one example, all the windows machines and linux virtual machines in this lab are on the ethernet subnet.  This organization is reflected in the IPv4 address structure; the netmask indicates the portion of the address that identifiies the subnet versus the host indentifier or index within that subnet, e.g., 255.255.255.0.  Certain addresses are special; 0 is the default router address and 255 is the broadcast address.  Windows ping is a bit broken, so it doesn't like to ping the broadcast address.  On linux use the broadcast option - e.g., ping -b 192.168.116.0 and see what happens.  ping -b 192.168.116.255. 

IPv6 makes these mechanisms much more systematic with the introduction of  well-known multicast addresses.  A good one page primer is available at http://www.estoile.com.  Let's try pinging some of these.  You need to use ping6 and you'll need to specify the interface of the link that you are interested in.  Note that IPv6 addresses are represented as a sequence of eight four-digit hex values, i.e., 16 bit units.  For example, 2001:5a8:4:3721:72:8572:88ac:9620.  The :: indicates a sequence of zeros that is long enough to fill the address up to 128 bits.   For example, 3000::214:a4ff:fe59:2fc0.  In this case, the 64-bit prefix is summarized concisely.  Sometimes the interface is carried along is a trailing %, e.g., fe80::214:22ff:fe45:91af%7.
Several other useful link local multicast addresses are defined.  These are used to bootstrap and manage the network.

IPv6  addresses consist of a prefix and an interface identifier.  The split is indicate but the scope.  For example, fe80::250:56ff:fec0:1/64 has a 64-bit prefix and a 14-bit interface identifier.  This is a particularly important address.  FE80:: is the link local unicast prefix.  The autoconfigured link local address of any device is formed by combining this prefix and its 64-bit unique identifier, essentially its MAC address.  Thus, nodes can assign themselves IP addresses and engage in link local communication without the assistance of any external agent.  That basic communication is used to obtain a routable IP address, i.e. an address with global, rather than local scope.  These steps are implemented in IPv4 with ad hoc link layer operations, such as ARP, RARP, BOOTP, and DHCP.  In IPv6 they are architected into ICMPv6 is a link independent fashion.

Network Applications and Services

As we work our way up the stack, we are going to jump over the transport layer (you are probably already familiar with UDP and TCP). There are basically two kinds of network applications,  remote terminals and services, and they utilize rather different application protocols.  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 within scripts.  You can try things out by hand.
As you type keys, the client application sends them to the remote terminal server, it echos characters back to the client, and the client prints them on the screen.  When the server sees the end of a line, it executes the specified command and sends the output back to the client for display.
This is how you move files over the (virtual) network between the windows and linux machines.  They are both on your desk and even both in the same physical machines, but you need to treat them as two completely independent machines on the hetwork.  This make them convenient for teaching networking concepts.

You could try to go the other way, (Linux SSH connecting out the Windows machine.) but you'l probably find that the windows side is not running a remote shell service.  We will mostly work withim the virtual linux machine because the networking support is much cleaner and all the software development tools we'll use are built in to it.

The more general case of remote processing 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.  Most of the time we use these protocols and services without thinking about them, because we just run the associated client application on our local machine.  However, in this class we will work with how all this stuff is put together.

Let's  break out of  our routine use of client applications and shake things up a little bit.  Pick a web site, say http://www.eecs.berkeley.edu/ and point a browser  to it.  The browser client is speaking the HTTP application protocol over TCP transport protocol over IP over all kinds of different links to a process on the server that is bound to port 80.  This process happens to be the web server.  It returns a bunch of text that your browser client kindly displays in a nice graphical form.  This is the human web.  We'll be working with the programmatic web.

We could make the same HTTP request programmatically using the command line tool CURL.  (Unless you hav cygwin installed, you'll need to do this on the Linux side.)
You see all that HTML come scrolling back. Not very useful in your terminal window.  But , you might use what comes back usefully by feeding it into a program that processes it.  (That is exactly what web crawlers doo.)  curl is a command line tool, but it speaks the HTTP application protocol.  It just doesn't render the HTML content that is exchanged by that protocol.  The network is completely agnostic to the application protocol.  HTTP GET requests and HTML response are just payload bits.

In fact, let's use the basic telnet application to connect to the HTTP port, issue the GET request to the server, and display the sequence of (HTML) characters that come back.
You typed in text that is the HTTP header information, terminated by a blank line.  The server, is listening on port 80.  It receved the header information and transmitted the requested page on the socket.  There is nothing special about the processes that conduct the exchange.  All that matters is what gets sent back and forther.

Telnet is not the most basic networking tool.  It is intended to be used for remote shells.  Characters are read from the user input and send to the server, which echos them back for display.  Enter causes the server to executed the command line and transmits the output, which is sent back to the client for display.

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. 
NC is a simple tool to get at low level networking without socket programming.  (We'll do some of too in just a little bit.)  Let's try talking a web server with it.
DISCUSS

LoWPAN Link

Wireless Embedded InterNetworking uses the standard low-power IEEE 802.15.4 RF link as an IP 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.  You can think of it like WiFi (which uses IEEE 802.11) but at much much lower power.  WiFi access points often functions at bridges - connecting two different links in the same subnet - rather than routers, which connect together different subnets using common or distinct link media.  WiFi can be utilized in either manner. Most of the hosts on the LoWPAN network will be small low-power embedded devices, i.e., motes.

Berkeley TelosB Mote

A Berkeley TelosB Mote is 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.  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


When the wireless sensor network research area took off about a decade ago, it was very important that the research community was able to consider all aspects of the solution to be a "open problem" - the architecture of the device, the operating system interface and concurrency model, the networking protocols, the application programming model.  Indeed, early studies on conventional machines (PC104s, ARMs), conventional operating systems( Linux, WinCE) and conventional networking stacks produced many negative results.  However, a decade of research progress, emergence of a low power IEEE standard radio, and development of the 6LoWPAN adaptation layer in the IETF has completely changed the landscape.  Rather than ad hoc network and system organizations hanging of the serial port of a PC, we can now obtain low power, reliable, predictable and secure embedded networks that  behave in familiar ways and have a consistent IPv6-based architecture.

LoWPAN Router

Networks connect to other networks through routers.  In this lab, we have used a commercially available LoWPAN router to provide this function.  It is essentially a Linux box runnting OpenWRT, much like the numerous WiFi Access Points on the market.  The major difference is that it has a 802.15.4 LoWPAN interface. IP packets are routeed to and from the network of motes over this interface.  This device also provides 6-to-4 translation (defined by IETF RFC XXX and widely available in Linux) so the embedded IPv6 network can interact with IPv4 networks easily.  Indeed, all the IPv6 communication in the embedded network is highly compressed for power, bandwidth and memory efficiency using the 6LoWPAN adaptation layer (IETF RFC 4944).

Basically, each student has a mote, but whole collections of these motes collective form an embedded IP network.  (We will probably run two such networks.)  They all provide routing for each other, as well as ICMPv6 services.  In class we will give specific directions for which network to use.

The network we will use in the lab looks something like the figure below.  The local network is the WAN of the LBR.  The actual addresses will depend on how the routers are configured.  Here this assumes that the LoWPAN router is configured with  FEC0:0:0:97/64 as the LoWPAN IPv6 prefix and 10.97.0.0 as the IPv4 subnet.  To see how your LoWPAN router is configured, open a brower to it using its IP address.  Click on the WAN tab.  This shows the local ethernet we are using to connect to this router. 
We may have one or more LoWPAN routers on the shared lab ethernet.  Each of them,  offers access to a distinct embedded subnet.  All the devices in that subnet have both IPv4 and IPv6 addresses.  Just like all of our desktop machines, they are sitting behind the NAT/Firewall so this is a further part of our private IP network.  We will have routing within our networks.  And, any of them can access the outside public internet as clients.  But, they are not exposed to the outside as servers.  Typcally, a subset of well adminstered machines in an organization are exposed as servers through the firewall.  Embedded networks often sit behind externally accessible servers, just as application servers and databases management systems sit behind web servers in any Internet service.  Internet protocols glue all the pieces of the Internet Service network together and all the pieces of the public Internet together, but the two connect through a restricted interface.

The LoWPAN tab shows how the LoWPAN network beyond this router is configured.
An alternate form of this architecture that we sometimes use for this lab essentially turns the Linux VM into a LowPAN router.  Linux supports a rich set of networking capabilities.  This alternative is described at the bottom of this page.  It runs the router as a linux process and uses a mote for the IEEE 802.15.4 LoWPAN interface.  It is possible to do the same thing with the router as a windows service.  This altenate configuration is describe in the appendix at the bottom of the page.

6LoWPAN router


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 supporta 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. 

Each of you have an Epic Interface Board that is designed for the purpose of Wireless Embedded Internetworking education, protoyping, and research.  All of the schematics for this are openly available through the Berkeley site- EPIC.  This includes a socket for the core Epic module, which is the essence of the mote.  It contains a microcontroller (TI MSP430), 802.15.4 radio (TI CC2410)  and flash storage.  In real application these modules can be easily mounted on application specific carrier board for a robust, cost-effective deployment.  Here, we are using a very flexible development platform for prototyping purposes.  The core module schematics are also all available on-line.  Like the prior Berkeley mote designs, it is available commercially as well.  (We design and build the hardware, but we don't distribute what we build.  We encourage companies to take that on, improve the manufacturability, etc.)

Each EPIC core module has a 64-bit EUID for its MAC address.  Since the modules are simply placed in a PLCC socket, the board has no such ID.  We have tried to put the EUID64 on your boards.  One thing we'll do is check that out in this lab. 

Your LoWPAN is what we used to call a Class B network, with 16-bit prefix and a 16-bit interface identifier.  At least when viewed as an IPv4 network.

Turn on your mote.  Connect to the LBR with your browser.  Navigate to the LoWPAN tab.  You should see your EUID64 show up in the Neighbors tab.  It has joined the network and been assigned an IP address via DHCP.  It has an IPv6 link local address wich is assigned directly through stateless autoconfiguration using the EUID64.  However, your desktop machine is not in its link local scope.  It has been assigned a routeable (global scope) IPv6 address which permits a unique 16-bit IEEE 802.15.4 short address to be assigned, as well as an IPv4 address.

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.

Find your node's EUID64 in the router tab.  As this is assigned by DHCP, it can potentially change.  But the lease is sticky enough that it will probably stay the same through the labs.

There you can see its IP addresses as well. In fact, you can see a synopsis of the routing for the whole network.   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.  If we were to spread these devices around the building, the LoWPAN network would get deeper with more hops. .

Establishing Routes

Your desktop machine knows how to talk to the ethernet interface of the LBR through its IP address on the lab network.  However, it does not know yet how to talk to the other interface, the LoWPAN interface, or the nodes on that link.  Establishing such routes is what routing protocols do.  But, just as IP address can be set manually, routes can be set manually.  This is done with the route tool.  Check on the Linux documentation for route using route -h and man route.

If the LoWPAN IPv4 subnet is 10.97.xx.xx and the LBR is 192.168.116.43, then the following adds a route from your linux VM to the LoWPAN network.  It says you go out on the eth0 interface to the gw address to find a class B subnet.

    sudo route add -net  10.97.0.0 netmask 255.255.0.0 gw 192.168.116.43  dev eth0

or in windows, find the interface number from route print.  Let's say 5.

    route add 10.97.0.0 mask 255.255.0.0 192.168.116.43 metric 3 if 5

The corresponding operation in IPv6 uses the IP tool.

    ip -6 route add <lowpanPrefix>::/64 via <LBRv6WANaddress>



DISCUSS

Simple IP network applications

The standard IP networking utilities can now be used to for the network embedded devices.   Above. you noted the IPv4 and IPv6 address of your mote and you enabled routing from your VM to the appropriate LoWPAN subnet.  Now lets go talk to the mote.  Replace 10.97 with the appropriate subnet address for your LoWPAN network.

Ping

Telnet

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. One important thing that embedded devices do is sense.  Various sensor are attached to the microcontroller through Analog-to-Digital Converters or through digital interfaces so they can be sampled.
We'll do a lot more sensing of interesting things.  The other critical thing that embedded devices do is actuate, i.e., control things. 
Let's look at the network from the mote's perspective.  We can do this because we are logged into the mote over the network.
If you have a router serving IPv6 for the laboratory LAN you could actually ping you VM from the mote.  If you only have a link local (FE80::) prefix, you won't be able to route there from the node.  Notice, that it is actually behaving as a telnet server for your VM.  In fact, your VM probably telneted in to the mote as if it were an IPv4 device.
Each of these motes is functioning as an IPv6 router.  The LoWPAN routable prefix is common to all the motes in our PAN.  The link local prefix corresponds to those motes that are in a single hop rom yours.

DISCUSS


Conclusion


At this point, we should look at the collective embedded IP network that we have formed.  We will move it around and examine its properties.


DISCUSS

Appendix


NAT mode VM alternative


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


VM-based Router with LoWPAN Nic alternative


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

========================================================================================================