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.
- Notice that IPv6 addresses are 128 bits. The upper 64 bits is the
prefix; this is essentially the generalization of an IPv4 subnet or
link. The lower 64 bits are the interface identifier. This
generalizes the machine number used in IPv4 subnets. The address
space is big enough that devices can assign themselves addresses
without any special consultation with higher authorities. DHCP is
also an integral part of IPv6.
- ping6 is the IPv6-icmp version of ping.
- In linux, ping the IPv6 LoWPAN interface with ping6
FEC0:0:0:9x7:: (The actual IPv6
prefix is shown on the setting of the LoWPAN tab.)
- In linux, ping the IPv6 motes using their IPv6 addresses shown in
the LBR Router tab.
- You can record these in environment variables in you linux bash
shell with export NODE1="fec0:0:0:97::5FE4" and then use ping6 $NODE1.
- You can also add entries to the hosts file. Pull down the
system adminstration tab and select network. Got to hosts and add.
- Open a remote shell on one of the motes using its IPv6 address,
eg. telnet FEC0:0:0:97::8bd.
- From there ping the 6LoWPAN interface of the route, ie. ping
FEC0:0:0:9x::
- exist the telosh
- IPv6 utilizes multicast groups as a fundamental organizational
principle. For example FF02::1 is the all nodes link local
multicast group. This can be used to discover all nodes on the
link associated with a particular interface. (In the NAT/bridge
configuration on linux, try ping6
-I tun0 FF02::1.)
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.
- In the moteshell try ping
FF02::1.
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?
- In the mote shell, ping one of the link local unicast
addresses that responded to the "all nodes" solicitation.
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.
- cd to $TOS/Echo
- You may want to browse the code you see there, but we'll explain
it later. If you want to compare it to traditional sockets
programming, a much more primitive TCP echo server example is here *** fix this link ***
- run make epic
to create an executible in ./build/epic.
- Notice that we are cross compiling in our linux environment for
the mote using gcc for the msp430. Actually, we are using an
extension to C for networking called NesC which produces C code.
- Ping nearby node’s swupdate status: swupdate
p <nodeIPaddress>
The response you see is the status of the firmware image on the node.
- Erase image from nearby
node:
swupdate
e <nodeIPaddress>
The OTA software update is smart about how it builds the
image. It can be stopped and restarted at any points; it will
just fill in the hole. By erasing it, we make sure that the image
is not up to date.
- Inject image to nearby
node:
swupdate
-t build/epic/tos_image.xml i <nodeIPaddress>
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.
- Reprogram to injected image at node: swupate
r fec0:0:0:97::6cc0
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
- telnet $NODEIP 7 or our new
friend nc
$NODEIP 7
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.
- In Linux, us NC to open an tcp connection to the echo service on
a node. Type short lines and long lines see how
it behaves. Be sure to exceed 128 characters.
- Use NC to send UDP datagrams to the ECHO
service. See what it does if the payload is too large to fit.
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.
- What does the IEEE 802.15.4 frame format look like? What is
the overhead of TCP vs UDP headers?
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.
- cd to trunk/tos/report and make epic
- upload the resulting executible to one of your nodes.
- we've built a special linux-side peer for this.
- cd to trunk/unix/ipv4
- make
- ./updreporter <moteIP address> 1221
Conclusion
Appendix
========================================================================================================
Association
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
motelist
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.