by Martin Turon, Director of Wireless Software, Crossbow Technology, Inc.

IPv6 was invented in 1998, over ten years ago, yet less than 1% of devices use it.

Why is IPv6 important?

The first answer is "lots of addresses".

Think of your PC and the RAM memory inside. Until recently, 32-bit processors were pervasive, and you couldn't put more than 4GB (4 billion bytes) of memory in them because of the limits in 32-bit address spaces. Now most new computers are 64-bit, and they can address 18 quintillion bytes. The Internet will eventually be forced to "upgrade" its address space as well. Currently over 99% of devices use IPv4 which uses 32-bit IP addresses that are most commonly displayed as 4 bytes in decimal: 192.168.1.100. If you want to host a web server to the world, you typically claim a static IP and one of the 4 billion possibilities is yours forever. But the population of the world is 6.7 billion, so there aren't enough to go around! And what if everyone wants multiple devices that can be uniquely addressed to serve some critical information like a cluster of wireless sensor nodes?

IPv6 is clearly the answer. It provides a 128-bit address space allowing for over 240 undecillion uniquely addressable devices. To put that in perspective, the soon-to-be 6.8 billion people in the world will each be able to have over 300 million subnets with over 18 quintillion devices in each one. That is a total of over 50 octillion uniquely addressable devices per person!  Note: The unallocated address pools in IPv4 are anticipated to be exhausted in 2012.

Which leads to the second answer: "government mandates".

In May 2009, the Federal CIO Council of the US government issued an official roadmap for IPv6 adoption. The report provides a detailed overview of the technology, it's benefits, tips on the various services and how to transition. It also tasks other government agencies with developing concrete plans for how they will deploy IPv6 and requires quarterly review of their progress.

"We can't keep operating in an IPv4 world when we're talking about sensor networks, wireless communications and mobile networks. We need more IP addresses - globally unique IP addresses - and that's what IPv6 provides. We need a target network architecture that's scalable, secure and stable." - Pete Tseronis, Federal IPv6 Working Group Chair and Deputy Associate CIO of the Department of Energy

Since the release of this document, a flurry of articles regarding IPv6 adoption has been written up in the press.

How can big IPv6 addresses fit on tiny motes?

Almost in anticipation of the recent uptick in IPv6 adoption, back in March some researchers at UC Berkeley released an Open Source implementation of IPv6 running on TinyOS 2.x called BLIP (Berkeley Low-power Internet Protocol). The BLIP stack runs on mote-class hardware, specifically the TelosB and MicaZ. How did they manage to fit a protocol that uses 128-bit addresses onto a platform with only 4KB of RAM? Well, beyond the fact that Stephen Dawson-Haggerty and other contributors are really really smart, the IETF has had a number of efforts to define ways for IPv6 to run on lossy, low bandwidth links for a while. The IETF timeline follows:

RFC 1883,2460 - IPv6 Specification
RFC 1885,4443 - ICMPv6 Internet control message protocol
RFC 3142 - IPv6-to-IPv4 translation
RFC 3315,4580,4649,4704 - DHCPv6 Dynamic, automatic address assignment
RFC 4861 - Neighbor Discovery
RFC 4862 - Stateless Addr Autoconf
RFC 4944 - IPv6 over IEEE 802.15.4 (6LowPAN) 

Drafts: HYDRO routing (part of ROLL [routing over low-power, lossy links] effort)

Papers: IP is dead, long live IP,  Extended Internet Architecture PhD Thesis by Jonathan Hui

Why is it cool?

IPv6 running on motes is cool because it really leverages what IPv6 was designed for -- ubiquitous computing.  Imagine a day when all of your appliances and consumer electronics will be able to talk to each other and provide you real time data on their energy usage, health, etc.  The ZigBee alliance has recently signed up to define a specification for an IPv6 stack in addition to an RF4CE stack for remote controls and consumer electronics.  Similar to how WiFi is integrated into all sorts of products today and just works, ZigBee may make it so cheap, tiny devices of the future can provide direct IPv6 connectivity over low-power, low-bandwidth radios.

BLIP is a work in progress.  It is currently fully supported on the TelosB platform and works on MICAz when compiled in a memory-constrained mode.  It is being folded into the TinyOS 2.x core with a slated release date of late August 2009.  The version in contrib/berkeley/blip is the correct one to use, however, as that one will actually build without manually adding radio stack modifications that are still being negotiated.  IRIS support is in the works as well with the initial port being done by European researchers Miklos Maroti and Lars Schor.  An improved release candidate of BLIP is slated to be pushed into contrib as early as next week.

Where can the BLIP source code be found?  How do you use it?

1) Download Xubuntos 2.1 VMware image (Howto)
2) Start the VM, login as:
  username: xubuntos
  password: tinyos
3) Start a Terminal
4) Prepare your VM to run BLIP as follows:

- Install IPv6 tools:

    sudo apt-get install netcat6

- Update tinyos-2.x trees from CVS:

    cd /opt
    # hit return for anonymous password
    cvs -d:pserver:anonymous@tinyos.cvs.sourceforge.net:/cvsroot/tinyos login
    cvs -z3 -d:pserver:anonymous@tinyos.cvs.sourceforge.net:/cvsroot/tinyos co -P tinyos-2.x
    cvs -z3 -d:pserver:anonymous@tinyos.cvs.sourceforge.net:/cvsroot/tinyos co -P tinyos-2.x-contrib/berkeley

- Add a simple environment setup script

cd /opt/tinyos-2.x-contrib/berkeley/blip
cat <<-EOF > setenv
export TOSROOT=/opt/tinyos-2.x
export TOSDIR=/opt/tinyos-2.x/tos
export LOWPAN_ROOT=$PWD
export TOSMAKE_PATH="$LOWPAN_ROOT/support/make"
EOF

- Build the driver

    cd /opt/tinyos-2.x/support/sdk/c/sf
    ./bootstrap
    ./configure
    make
    cd /opt/tinyos-2.x-contrib/berkeley/blip/support/sdk/c/blip
    make

- Patch motelist to handle mib520 for micaz discovery

cd ~
cat <<-EOF > motelist-linux.mib520.patch
--- motelist-linux	2006-12-12 10:23:01.000000000 -0800
+++ /usr/bin/motelist	2009-05-19 11:28:26.000000000 -0700
@@ -61,7 +61,10 @@ sub scan_sysfs {
 
 # Scan /sys/bus/usb/drivers/usb for FTDI devices
 my @ftdidevs =
- grep { (\$_->{UsbVendor}||"") eq "0403" && (\$_->{UsbProduct}||"") eq "6001" }
+ grep { (\$_->{UsbVendor}||"") eq "0403" && 
+ (((\$_->{UsbProduct}||"") eq "6001") || 
+ ((\$_->{UsbProduct}||"") eq "6010")) 
+ }
 map { {
 SysPath => \$_,
 UsbVendor => snarf("\$_/idVendor",1),
EOF
cd /usr/bin
sudo patch -p0 < motelist-linux.mib520.patch

- Download Blip.micaz.patch

 - Patch the blip contrib sources to add automatic micaz support
and fix some build issues.

    cd /opt/tinyos-2.x-contrib/berkeley/blip
    patch -p0 < ~/blip.micaz.patch

5) Use your prepared VM to build and deploy BLIP:

- Enable the BLIP build environment:

    cd /opt/tinyos-2.x-contrib/berkeley/blip
    source setenv

- Build the UDPEcho app and base station for telosb and micaz:

    cd /opt/tinyos-2.x-contrib/berkeley/blip/apps/UDPEcho
    make telosb blip
    make micaz blip

    cd /opt/tinyos-2.x-contrib/berkeley/blip/apps/IPBaseStation
    make blip telosb
    make blip micaz

- Connect a TelosB via USB, and flash it with the base station code
(Install FTDI drivers if needed)
(Accept TelosB device when dialog appears)
(Right click USB device in lower right of VM and select connect)

    motelist # find ttyUSB port to use
    cd /opt/tinyos-2.x-contrib/berkeley/blip/apps/IPBaseStation
    make blip telosb install,64 bsl,/dev/ttyUSB0

- Connect a MicaZ via USB, and flash it with the remote node code
  (Install FTDI drivers if needed)
  (Accept MIB520 device when dialog appears)
  (Right click USB device in lower right of VM and select connect)

 	 
    motelist # find ttyUSB port to use
    cd /opt/tinyos-2.x-contrib/berkeley/blip/apps/UDPEcho
    make blip micaz install,1 mib520,/dev/ttyUSB0

6) Fire up Linux network driver to communicate with BLIP network:

- Start the ip-driver

    cd /opt/tinyos-2.x-contrib/berkeley/blip/support/sdk/c/blip
    sudo ./ip-driver /dev/ttyUSB0 telosb
    # password: tinyos	 
    # blip console commands:
    # blip:xubuntos-tinyos> help
    # blip:xubuntos-tinyos> log WARN
    # blip:xubuntos-tinyos> routes	

7) Use standard IPv6 tools to access the remote BLIP nodes:

    # Ping - base station and remote node
    ping6 2001:470:1f04:56d::64
    ping6 2001:470:1f04:56d::1

    # Access shell on remote node
    nc6 2001:470:1f04:56d::1

Note that BLIP ships with support for pinging a node with standard the ping6 tool, shelling into a node with netcat (the shell is a custom one, not ssh, type help to see available commands), and over-the-air reprogramming of nodes with a deluge-like interface.  BLIP is an exciting software development for the TinyOS community and users of TelosB, MICAz, and soon IRIS platforms.  We encourage you to try it and track its rapid development.

Martin Turon is Crossbow's Director of Wireless Software. Not only an expert in the field of wireless sensor networks, Martin has been instrumental in simplifying the WSN user experience with advancements in interface and server tools using his background in video game design, mobile phone software and operating systems. He is the current Chair of the ZigBee WSN group which is working to establish the standard for low-power routing while leading the Wireless software development team at Crossbow for future product enhancement. Martin obtained degrees from University of California, Berkeley in Electrical Engineering and Computer Science. He has also studied Artificial Intelligence at University of California, Los Angeles and received a certificate in Math for Financial Engineering from Haas Business School. Martin is an avid lover of indie rock and performs with various ad-hoc musical projects.

The Times of India reported today on a wireless sensor solution developed by students of Amrita Vishwa Vidyapeetham University for landslide detection. This development effort used Crossbow's MICAz Mote platform and was done in collaboration with the European commission and Indian Space Research Organisation (ISRO). This pilot deployment of India's first landslide detection system with wireless sensor networks was put in place at Munnar, Idukki, Kerala, India. This implementation brought together scientists from diverse fields such as geology and geophysics, mechanical,computer, electrical, electronics, and communication engineering to save human lives, preserve the environment, and mitigate property damage.

The devastation and loss of life caused by landslides affects hundreds of people every year around the world. Amrita University's rainfall induced landslide detection system uses a heterogeneous network that included wireless sensor networks in combination with Wi-Fi and satellite technology. The pilot site chosen for this study is highly prone to landslides due to systemic monsoon induced rainfalls in the region.

"Landslides occur frequently in mountainous terrains, especially during monsoons but detecting them in advance is not an easy task,'' says Dr P Venkat Rangan, vice chancellor, Amrita university. An expert in wireless communication, Rangan led a team of students in developing the model that has become operational in Munnar town in the Idukki district of Kerala.

This breakthrough technological system was developed as part of the research project WINSOC (Wireless Sensor Network with Self-Organisation Capabilities for Critical and Emergency Applications). Wireless panels with sensor nodes to read different soil parameters such as moisture, vibration and movement were embedded 15 metres beneath the earth at different points, says Maneesha Ramesh, a faculty member, who was part of the project.

The actual deployment site in the Idukki district built on the existing setup at Munnar as it provided the infrastructure needed for retrieving geological and hydrological data from the field as it was necessary for the data to be transmitted a long distance for further analysis. The data received from the geophysical sensors were transmitted through the wireless sensor network which used a two layer hierarchical topology.

The sensors were attached to a wireless transmission device, in this case Crossbow's MICAz Mote platform, which would then convert the analog value into a digital value and send the inputs to the base stations, which were connected to Amrita mutt's Kollam campus. "Experts will be monitoring the inputs from the base stations in real time and any unusual behaviour or extreme value will trigger an alarm,'' says Dr Rangan.

Multiple sets of geophysical sensors are located in a distributed manner inside a column, referred to as the 'sensor column'. The sensor columns are approximately 5 -6 meters long and are buried deep inside the earth and the data from them are retrieved using lower layer wireless sensor nodes attached to the sensor columns.

The lower layer wireless sensor nodes were wirelessly connected to a hierarchy of upper level wireless nodes that would forward the data on to a Gateway. The data was then sent via a directional Wi-Fi link to a Field Data Management Center (FMC). The data was then forwarded over a satellite link to the Data Management Center (DMC) which has sophisticated landslide data processing and modeling capability, located at Amrita University, Amritapuri campus which is situated approximately 252 kilometers away from the deployment field.

The fully tested model has become operational in Munnar. The system can be deployed in any part of the country prone to landslides and snow avalanches. The application could also be put to industrial use for the study of gas leakages or in conservation of forests by early identification of forest fires during summer.

As part of this project, representatives from various European partners like University of Rome, Selex Communications, Intracom Telecom, Czech Centre for Science and Technology arrived at the Amrita University to learn about the first-ever wireless sensor network system for landslide detection. The Amrita wireless sensor network system for landslide detection has been developed as part of WINSOC which is co-funded by INFSO DG of European Commission.

Crossbow's eKo system was prominently featured in the Press Democrat this week. The article highlights the importance of irrigation management and water conservation as well as the use of stress irrigation to grow higher quality grapes. Several systems were installed in Napa's Alexander Valley to highlight the benefits of using water monitoring systems. Crossbow's eKo system was one of these solutions.

To view the entire article, click here.

Six different irrigation systems are being installed side by side in an Alexander Valley vineyard in a demonstration of water conservation.

“We are looking at deep irrigation versus shallow, night versus day, one emitter per vine versus two,” said Mark Greenspan of Advanced Viticulture of Santa Rosa, a grower’s consulting firm.

The concept is to reduce water use by 10 to 20 percent, a conservation goal that is increasingly important this year as the North Coast suffers through another drier-than-normal year.

“I think it’s very valuable, potentially,” said Nick Frey, president of the Sonoma County Wine Grape Commission. “People change farming practices when they are convinced they can do it and it is not risky. If you can show that they can reduce water and produce a good grape crop, it is very valuable.”

The project at Hoot Owl Creek Vineyard is being financed by the Sonoma County Water Agency. The agency this year is under a proposed state order to reduce summertime flows in the Russian River and cut the amount of water it takes from the river by 25 percent to conserve water in Lake Mendocino for the fall salmon run. The state Water Resources Control Board is also proposing that conservation goals of 50 percent be set for Mendocino County and 25 percent for Sonoma County, and irrigating commercial turf be banned.

Grape growers farm about 60,000 acres in Mendocino County and in Alexander and Russian River valleys in Sonoma County. They use a third of the water in the Russian River watershed, according to water agency officials.

Greenspan believes that growers routinely over-irrigate vineyards, irrigating once a week for eight hours, using about eight gallons per vine. But that water goes too deep, soaking the soil past the root system. Roots go down as much as three feet in the soils that are common in the Russian River watershed, Greenspan said.

“You will lose a lot of water below the root system,” Greenspan said. “We want to stress the vines to produce good grapes, but not over-stress. We want less water and more often.”

Greenspan said his irrigation method has been used in a Beaulieu Vineyard ranch in Napa County for the past year, and saves 10 to 20 percent in water use. At Hoot Owl Creek Vineyard, the different irrigating systems are being installed on a half-acre plot of eight-year-old cabernet sauvignon vines. Moisture and temperature sensors will be used to monitor the soil and grapes in real time. The measurements will be sent by solar-powered transmitters from the vineyard to an Internet site, where they will be available for anyone to see.

By BOB NORBERG

To truly understand the return on investment (ROI) growers can expect to receive from using a water system management tool like the eKo platform, growers can use the eKo ROI calculator to determine how much they would need to spend to outfit their vineyard with the eKo solution and the time period during which their payback would be realized. For more information on the eKo system, visit Crossbow's site. To input your data and determine your return on investment click on the calculator below:

This past Saturday, May 2nd, the 135th running of the Kentucky Derby took place at Churchill Downs in Louisville, Kentucky. In an improbable ending, Jockey Calvin Borel rode Mine That Bird - a 50-1 longshot - to a huge victory, coming from dead last to win by 6 3/4 lengths. The Kentucky Derby is often billed as "the most exciting two minutes in sports", and Borel and Mine That Bird did their best to live up to that standard. 

The power and force exerted by these animals in those 2 minutes is amazing! A robotic hoof mechanism was shown at the derby. The image below shows the device clad with an aluminum shoe. The mechanism simulates the force, angle and impact of a racehorse hoof, and makes measurements to help detect trouble spots on tracks. Professor Mick Peterson demonstrated the machine while testing the racing surface at Churchill Downs on Saturday, April 25th, the week before the race.

The device used one of Crossbow's accelerometers to collect the data necessary to make these measurements. These accelerometers provide superior performance in small packages. With expertise in MEMS (Micro-Electro-Mechanical Systems) and DSP (Digital Signal Processing) technology, Crossbow accelerometers deliver reliable, cost-effective solutions across a wide range of applications. Several different accelerometers are offered, each optimized to meet customer needs in targeted fields.

Prof. Mick Peterson's research at University of Maine on Animal Biomechanics takes engineering technology and applies it to real life situations. Creating the robotic hoof allows owners the comfort of knowing that the track is safe for the horses to race on, offers them a playing field to encourage optimal performance and provides a fair and consistent racing surface to all riders. The device allows owners to understand the exercise impact of various tracks on the bone density of the horses, and the modeling done by the machine suggests that the device measures soil properties more than 1 foot beneath the track's surface. For more information on this research visit Professor Peterson's site here and for details on Crossbow's accelerometers, click here.

Congratulations to Kentucky Derby Winner Mine Than Bird and Borel for an amazing win!